[issue14512] Pydocs module docs server not working on Windows.
Terry J. Reedy tjre...@udel.edu added the comment: C:\Programs\Python32\Tools\Scripts..\..\pythonw pydocgui.pyw -b has the same behavior I described. So does -g. The shortcut has been part of the Windows installation for many versions. It obviously uses pydocgui.py. C:\Programs\Python32\Libpydoc.py -b # starts one python.exe process # prints on the next lines in the command window Server ready at http://localhost:50695/ Server commands: [b]rowser, [q]uit server # and opens blank localhost:50695 browser window after asking for permission for python to access local network (which I gave). 'b' at prompt opens another blank window. C:\Programs\Python32\Libpydoc.py -w difflib #prints wrote difflib.html #which it did, looking as expected when opened in browser, with lots of cross-links. So what it seems is not working in either case is opening the html page in the browser or connecting it to the server. C:\Programs\Python32\Libwebbrowser.py python.org opens the page in *Internet Explorer* rather than Firefox (my default browser). pydoc tried to connect to the server in a new FF tab. When I re-ran pydoc and tried to open localhost:50695 in IE, it gave me the result of a Bing search (one help forum post), so neither browser can find anything at that url. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14512 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14521] math.copysign(1., float('nan')) returns -1.
Mark Dickinson dicki...@gmail.com added the comment: The pickle issue occurs in the numpy module, on windows I'm still not clear what the issue is. Is there something wrong in the output of the pickle example you show? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14521 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14539] logging module: logger does not print log message with logging.INFO level
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment:
You haven't configured any handlers for the logger, so by default it wouldn't
actually log anything. However, when no handlers are configured, logging uses
an internal last resort handler to print the message to sys.stderr, and this
handler has a threshold of WARNING (it's meant to print stdlib warnings and
errors when no handlers are configured by an application).
If you add the lines, you should see something like this:
logging.basicConfig(level=logging.INFO, format='%(message)s')
logging.info('info message')
info message
See
http://docs.python.org/py3k/howto/logging.html#what-happens-if-no-configuration-is-provided
for more information.
--
assignee: - vinay.sajip
resolution: - invalid
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14539
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14423] Getting the starting date of iso week from a week number and a year.
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: -haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14423 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14521] math.copysign(1., float('nan')) returns -1.
mattip matti.pi...@gmail.com added the comment:
The pickle output has the sign-bit set. Ignoring the sign-bit, it is unpickled
correctly. However math.copysign using this value will now return minus on
platforms where copysign(3., float('nan')) is known to work.
Perhaps the whole can of worms should not have been opened in the first place.
Another solution would be to raise a ValueError if copysign(x, float('nan')) is
called...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14521
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14521] math.copysign(1., float('nan')) returns -1.
Mark Dickinson dicki...@gmail.com added the comment:
The pickle output has the sign-bit set. Ignoring the sign-bit, it is
unpickled correctly.
Okay, thanks for the clarification. I just wanted to be clear whether there's
a real problem with pickle that should be fixed in 2.7 or not.
Again, I don't see this as a bug: pickle is transferring the sign bit
correctly, so the only issue again is that float('nan') happens to produce a
nan whose sign bit is set (depending on platform, compiler options, etc.). I
don't see it as a problem that one can end up with some 'positive' nans and
some 'negative' nans on a single system. As far as I know, none of this
violates any documentation or standards (IEEE 754 explicitly places no
interpretation on the sign bit of a nan, and makes no guarantees or
recommendations about the sign bit of the result of converting the string
'nan'). So at worst, this is a minor violation of user expectations. Though I
do agree that having float('-nan') having its sign bit unset is especially
surprising.
So while I don't see this as a bug that should be fixed for 2.7, I'm happy to
'fix' this for Python 3.3, partly for the portability improvement, and partly
to avoid having the string-to-float conversions do INF*0 calculations at run
time; that bit's always made me feel uncomfortable.
Thanks for the updated patch; I'll take a look shortly.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14521
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14423] Getting the starting date of iso week from a week number and a year.
Esben Agerbæk Black esbe...@gmail.com added the comment: I believe that it is a good solution to have, for lack of a better term; bi-directional features so in my opinion .isocalendar() merits having a constructor that takes an ISO format. Sadly no :-( I looked it over once more and it seems there is an error where the date is not offset correctly for years beginning on Tuesday, Wednesday or Thursday. I will updater my patch ASAP. +if self.isocalendar()[1] != 1: +if self.weekday() 3: # Jan 1 is not in week one + self += timedelta(7 - self.weekday()) +else: +self -= timedelta(self.weekday()) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14423 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14423 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8799] Hang in lib/test/test_threading.py
Kristján Valur Jónsson krist...@ccpgames.com added the comment: We shouldn't be testing implementation details. The Condition variables are canonically prone to spurious wakeups and stolen wakeups. The fact that the current implementation doesn't have them shouldn't place that burden on future implementations of threading.Condition on this platform. From the docs: Note: Condition variables can be, depending on the implementation, subject to both spurious wakeups (when wait() returns without a notify() call) and stolen wakeups (when another thread acquires the lock before the awoken thread.) For this reason, it is always necessary to verify the state the thread is waiting for when wait() returns and optionally repeat the call as often as necessary. 2) You would build a lock yourself if you wanted exact control over its behaviour. In this case, we are just doing what threading.Lock() does, but it could be more complicated. At any rate, it proves a useful toy usage of a condition variable in the context of making sure that it works properly as part of the unit tests. I could leave the original test in place and just add the new ones, but the old test is at least provably a subject to a race condition as per the original issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8799 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14478] Decimal hashing very slow, could be cached
Stefan Krah stefan-use...@bytereef.org added the comment: I think it would be a good idea to fix this in the Python version for the other implementations. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14478 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8799] Hang in lib/test/test_threading.py
Antoine Pitrou pit...@free.fr added the comment: The Condition variables are canonically prone to spurious wakeups and stolen wakeups. No, they aren't. Just because POSIX says they are doesn't mean *our* condition variables are the same. Spurious wakeups are an annoyance, and our implementation AFAICT never exhibited them. From the docs: Note: Condition variables can be, depending on the implementation, subject to both spurious wakeups (when wait() returns without a notify() call) and stolen wakeups (when another thread acquires the lock before the awoken thread.) For this reason, it is always necessary to verify the state the thread is waiting for when wait() returns and optionally repeat the call as often as necessary. Ah, thanks, indeed. Except that... this was added by yourself in 483bbebc57bf, after issue 10260, but *without* being part of the original patch that you uploaded on that issue. So this never got reviewed and was instead sneaked in the docs in a commit of yours. Unless other people disagree, I think this addition should be reverted. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8799 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14423] Getting the starting date of iso week from a week number and a year.
Antoine Pitrou pit...@free.fr added the comment: No, but it is still a one-line function that those who need it can easily implement. It's so easy that the patch isn't a one-liner and it seems to still have bugs wrt. intended behaviour. I am on the fence here because we already have date.isocalendar() function, so it is natural to desire its inverse, but still at least on this side of the pond an Easter(year) date constructor would see more use than that. This isn't an either/or situation. We can have both from_iso_week() and Easter() if both are useful. And I don't get this side of the pond argument. Python is not meant only for the American public, that's why all strings are now unicode. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14423 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows
R. David Murray rdmur...@bitdance.com added the comment: delete_after what? I know it is somewhat implicit in the fact that it is a context manager call, but that is not the only context the method name will be seen in. (eg: 'dir' list of methods, doc index, etc). Even as a context manager my first thought in reading it was delete after what?, and then I went, oh, right. How about delete_on_exit? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows
R. David Murray rdmur...@bitdance.com added the comment: By the way, I still think it would be nicer just to have the context manager work as expected with delete=True (ie: doesn't delete until the end of the context manager, whether the file is closed or not). I'm OK with being voted down on that, though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows
Antoine Pitrou pit...@free.fr added the comment: By the way, I still think it would be nicer just to have the context manager work as expected with delete=True (ie: doesn't delete until the end of the context manager, whether the file is closed or not). I'm OK with being voted down on that, though. Indeed, the current behaviour under Windows seems to be kind of a nuisance, and having to call a separate method doesn't sound very user-friendly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows
Jason R. Coombs jar...@jaraco.com added the comment: I agree. If the primary usage of the class does not work well on Windows, developers will continue to write code using the primary usage because it works on their unix system, and it will continue to cause failures when run on windows. Because Python should run cross-platform, I consider this a bug in the implementation and would prefer it be adapted such that the primary use case works well on all major platforms. If there is a separate class method for different behavior, it should be for the specialized behavior, not for the preferred, portable behavior. I recognize there are backward-compatibility issues here, so maybe it's necessary to deprecate NamedTemporaryFile in favor of a replacement. -- title: tempfile.NamedTemporaryFile not particularly useful on Windows - tempfile.NamedTemporaryFile not particularly useful on Windows ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4892] Sending Connection-objects over multiprocessing connections fails
sbt shibt...@gmail.com added the comment: Updated patch which uses ForkingPickler in Connection.send(). Note that connection sharing still has to be enabled using allow_connection_pickling(). Support could be enabled automatically, but that would introduce more circular imports which confuse me. It might be worthwhile refactoring to eliminate all circular imports. -- Added file: http://bugs.python.org/file25167/mp_pickle_conn.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4892 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14423] Getting the starting date of iso week from a week number and a year.
Alexander Belopolsky alexander.belopol...@gmail.com added the comment: On Tue, Apr 10, 2012 at 6:44 AM, Antoine Pitrou rep...@bugs.python.org wrote: It's so easy that the patch isn't a one-liner and it seems to still have bugs wrt. intended behaviour. Unless I miss something, the inverse to isocalendar() is simply from datetime import * def fromiso(year, week, day): d = date(year, 1, 4) return d + timedelta((week - 1) * 7 + day - d.isoweekday()) At least it works in my testing: (2012, 15, 2) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14423 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows
R. David Murray rdmur...@bitdance.com added the comment: Well, fixing NamedTemporaryFile in either of the ways we've discussed isn't going to fix people writing non-portable code. A unix coder isn't necessarily going to close the file before reading it. However, it would at least significantly increase the odds that the code would be portable, while the current situation *ensures* that the code is not portable. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14541] test_sndhdr fails when run from an installation
New submission from Vinay Sajip vinay_sa...@yahoo.co.uk: test_sndhdr fails when run from an installed Python, due to a missing directory in the installation. The attached patch should rectify this. -- components: Library (Lib) files: Makefile.pre.in.diff keywords: easy, patch messages: 157953 nosy: georg.brandl, vinay.sajip priority: normal severity: normal status: open title: test_sndhdr fails when run from an installation type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file25168/Makefile.pre.in.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14541 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14541] test_sndhdr fails when run from an installation
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: Whoops, I think I added Georg when I meant Victor ... -- nosy: +haypo -georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14541 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14478] Decimal hashing very slow, could be cached
Jim Jewett jimjjew...@gmail.com added the comment: Stefan Krah has a good point. Since the only cost is an extra slot, and this is for users who have already chosen to use Decimal instead of a more efficient (but possibly less accurate) representation, even without the native speedups to Decimal ... I guess I'm now +1. It is clearly an implementation detail, so I don't think the docs need to be changed. I'm not sure the tests do, nor am I sure *how* to test for it in a black-box fashion. I have reviewed the patch and have no objections. So unless a new objection comes up in the next few days, I would say this is ready to be checked in. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14478 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14478] Decimal hashing very slow, could be cached
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset a012d5df2c73 by Stefan Krah in branch 'default': Issue #14478: Cache the hash of a Decimal in the C version. http://hg.python.org/cpython/rev/a012d5df2c73 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14478 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14478] Decimal hashing very slow, could be cached
Stefan Krah stefan-use...@bytereef.org added the comment: I changed the C version to cache the hash as well: For the submitted test case the speedup is only 5x, but hashing times vary greatly depending of the size of the coefficient and the exponent. BTW, the tests already call both hash() and __hash__() on the same number, so retrieving the cached value is actually tested. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14478 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14541] test_sndhdr fails when run from an installation
STINNER Victor victor.stin...@gmail.com added the comment: Data files were added by the issue #9243 for new tests. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14541 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14478] Decimal hashing very slow, could be cached
Stefan Krah stefan-use...@bytereef.org added the comment: The patch for the Python version looks good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14478 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4892] Sending Connection-objects over multiprocessing connections fails
Antoine Pitrou pit...@free.fr added the comment: Support could be enabled automatically, but that would introduce more circular imports which confuse me. Are you sure? AFAICT: - connection depends on forking - reduction depends on forking and connection But connection doesn't depend on reduction, neither does forking. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4892 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14541] test_sndhdr fails when run from an installation
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: Data files were added by the issue #9243 for new tests. That's fine, it's just that the Makefile needs to include the new directory test/sndhdrdata (which my patch does). I could have committed the change, but thought you should be in the loop. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14541 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14478] Decimal hashing very slow, could be cached
Serhiy Storchaka storch...@gmail.com added the comment:
The patch for the Python version looks good to me
Oh, but used by James Hutchison approach is faster. When I disable the
_decimal:
Unpatched:
int: 2.24056077003479
CachingDecimal: 8.49468207359314
Decimal: 187.68132972717285
With rhettinger's LBYL patch:
int: 2.1670639514923096
CachingDecimal: 8.790924310684204
Decimal: 10.426796436309814
With EAFP patch:
int: 2.1392786502838135
CachingDecimal: 8.431122303009033
Decimal: 8.263015270233154
--
Added file: http://bugs.python.org/file25169/decimal_hash_2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14478
___diff -r a012d5df2c73 Lib/decimal.py
--- a/Lib/decimal.pyTue Apr 10 16:27:58 2012 +0200
+++ b/Lib/decimal.pyTue Apr 10 18:46:19 2012 +0300
@@ -547,7 +547,7 @@
class Decimal(object):
Floating point class for decimal arithmetic.
-__slots__ = ('_exp','_int','_sign', '_is_special')
+__slots__ = ('_exp','_int','_sign', '_is_special', '_hash')
# Generally, the value of the Decimal instance is given by
# (-1)**_sign * _int * 10**_exp
# Special values are signified by _is_special == True
@@ -983,6 +983,10 @@
def __hash__(self):
x.__hash__() == hash(x)
+try:
+return self._hash
+except AttributeError:
+pass
# In order to make sure that the hash of a Decimal instance
# agrees with the hash of a numerically equal integer, float
@@ -992,20 +996,22 @@
if self.is_snan():
raise TypeError('Cannot hash a signaling NaN value.')
elif self.is_nan():
-return _PyHASH_NAN
+hash_ = _PyHASH_NAN
else:
if self._sign:
-return -_PyHASH_INF
+hash_ = -_PyHASH_INF
else:
-return _PyHASH_INF
-
-if self._exp = 0:
-exp_hash = pow(10, self._exp, _PyHASH_MODULUS)
+hash_ = _PyHASH_INF
else:
-exp_hash = pow(_PyHASH_10INV, -self._exp, _PyHASH_MODULUS)
-hash_ = int(self._int) * exp_hash % _PyHASH_MODULUS
-ans = hash_ if self = 0 else -hash_
-return -2 if ans == -1 else ans
+if self._exp = 0:
+exp_hash = pow(10, self._exp, _PyHASH_MODULUS)
+else:
+exp_hash = pow(_PyHASH_10INV, -self._exp, _PyHASH_MODULUS)
+hash_ = int(self._int) * exp_hash % _PyHASH_MODULUS
+if self 0: hash_ = -hash_
+if hash_ == -1: hash_ = -2
+self._hash = hash_
+return hash_
def as_tuple(self):
Represents the number as a triple tuple.
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4892] Sending Connection-objects over multiprocessing connections fails
sbt shibt...@gmail.com added the comment: But connection doesn't depend on reduction, neither does forking. If registration of (Pipe)Connection is done in reduction then you can't make (Pipe)Connection picklable *automatically* unless you make connection depend on reduction (possibly indirectly). A circular import can be avoided by making reduction not import connection at module level. So not hard to fix. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4892 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14541] test_sndhdr fails when run from an installation
STINNER Victor victor.stin...@gmail.com added the comment: Python 3.2 should also be fixed. You may need to patch Tools/msi/msi.py in Python 3.2, not in Python 3.3 (see changeset fb7bb61c8847). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14541 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14478] Decimal hashing very slow, could be cached
James Hutchison jamesghutchi...@gmail.com added the comment: In the patch: This: +except AttributeError: +pass should be: +except: everything inside except statement Checking for the AttributeError is very slightly slower. Not by a lot, but I think if we're going for speed we might as well be as fast as possible. I can't imagine any other exception coming from that try statement. Using except: pass as opposed to sticking everything inside the except statement is also very slightly slower as well Simple test case, 10 million loops: except: 7.140999794006348 except AttributeError: 7.8440001010894775 Exception code in except: 7.48367575073 after except/pass: 7.75 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14478 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14478] Decimal hashing very slow, could be cached
Serhiy Storchaka storch...@gmail.com added the comment: I can't imagine any other exception coming from that try statement. KeyboardInterrupt -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14478 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14478] Decimal hashing very slow, could be cached
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: Checking for the AttributeError is very slightly slower Why are you trying to micro-optimize the Python version, when the C implementation does it better and faster? -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14478 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8799] Hang in lib/test/test_threading.py
Kristján Valur Jónsson krist...@ccpgames.com added the comment: Stolen wakeups are a fact of life though, even in cpython's implementation of condition variables. And for the user of a condition variable the difference is so subtle as to not warrant special mention. This is, btw, not just a posix thing. It is same on windows, java, and in fact, comes from the original definition of a condition variable as part of the monitor pattern. Condition variables are defined have this caveat to allow for flexibility in their implementation. Look anywhere in the internets and you will find this, including here: http://www.cs.berkeley.edu/~kubitron/courses/cs162/hand-outs/synch.html The canonical and correct way to use a condition variable is to repeatedly wait() and verify that the wakeup condition holds. The wait_for() method abstracts this into a convenient helper. There is no need to befuddle the issue by special casing the python version as being guaranteed to not have suprious wakeups, but otherwise do have the stolen thread problem. Quite the contrary, we should be careful to never overspecify our interfaces so that we may not change their ipmlementation details later. A good summary of the situation and the reason for the specification can be found here: http://stackoverflow.com/questions/8594591/why-does-pthread-cond-wait-have-spurious-wakeups The comment I added to the documentation clarifies the reason why other examples in the docs were using while loops and teaches shows people how to use these constructs in a robust manner. Removing it is a bad idea and I think you will find others will agree. Take it up on python-dev if you want. Unless you disagree, I'll add these test cases in addition to the broken one, which can then be fixed or removed later if it turns out to be problematic to other people. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8799 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14478] Decimal hashing very slow, could be cached
Serhiy Storchaka storch...@gmail.com added the comment: Using except: pass as opposed to sticking everything inside the except statement is also very slightly slower as well I ran the test several times and didn't see the difference between pass and sticking variants more than between different runs of the same variant. If it is, then this is a reason for the interpreter optimization. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14478 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14541] test_sndhdr fails when run from an installation
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset b2242224fb7f by Vinay Sajip in branch '3.2': Issue #14541: Added test/sndhdrdata to Makefile.pre.in for installation. http://hg.python.org/cpython/rev/b2242224fb7f New changeset 54bc19fc5b46 by Vinay Sajip in branch 'default': Issue #14541: Merged addition of test/sndhdrdata to Makefile.pre.in from 3.2. http://hg.python.org/cpython/rev/54bc19fc5b46 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14541 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14541] test_sndhdr fails when run from an installation
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: Closing, as msi.py for 3.2 appears to already include sndhdrdata. -- assignee: - vinay.sajip resolution: - fixed status: open - closed versions: +Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14541 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8799] Hang in lib/test/test_threading.py
Charles-François Natali neolo...@free.fr added the comment: The Condition variables are canonically prone to spurious wakeups and stolen wakeups. No, they aren't. Just because POSIX says they are doesn't mean *our* condition variables are the same. Spurious wakeups are an annoyance, and our implementation AFAICT never exhibited them. I agree with Antoine. Spurious wakeups are an implementation issue (mainly has to do with efficiency on SMP systems and interrupted syscalls), but are definitely not a part of the standard API. Since our implementation doesn't exhibit this problem, there's no reason to scare and confuse people. For example, our locks are special in the sense that they can be released by a thread other than the one that acquired it, etc, and this behavior is documented. However, while I think the spurious wakeups reference could be removed, I think that the advice of repeatedly chcking the invariant shoud be kept, because it is always desirable (stolen wakeup, and better logic). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8799 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8799] Hang in lib/test/test_threading.py
Antoine Pitrou pit...@free.fr added the comment: Stolen wakeups are a fact of life though, even in cpython's implementation of condition variables. And for the user of a condition variable the difference is so subtle as to not warrant special mention. I don't think it's a subtle difference. Being woken up too late is not the same as being woken up spuriously. Also, the term stolen wakeup makes it unnecessarily dramatic. There is no stealing involved here. Look anywhere in the internets and you will find this, including here: http://www.cs.berkeley.edu/~kubitron/courses/cs162/hand-outs/synch.html Thanks, will take a look. Quite the contrary, we should be careful to never overspecify our interfaces so that we may not change their ipmlementation details later. The interface is already, de facto, specified by its one and only implementation, which has been in use for a long time. It's also specified by its documentation, before it was silently modified by you. There's probably code out there that relies on wait() not returning prematurately. A good summary of the situation and the reason for the specification can be found here: http://stackoverflow.com/questions/8594591/why-does-pthread-cond-wait-have-spurious-wakeups So the reason appears to be: “Spurious wakeups may sound strange, but on some multiprocessor systems, making condition wakeup completely predictable might substantially slow all condition variable operations.” Python is a high-level language, so making condition variable ops substantially slower is not a blocking issue for us. What follows is even less enlightening: “The intent was to force correct/robust code by requiring predicate loops. This was driven by the provably correct academic contingent among the core threadies in the working group, though I don't think anyone really disagreed with the intent once they understood what it meant.” The comment I added to the documentation clarifies the reason why other examples in the docs were using while loops and teaches shows people how to use these constructs in a robust manner. Teaching people to use loops is fine. But there's no need to mislead them with inaccurate descriptions of the implementation's behaviour. Unless you disagree, I'll add these test cases in addition to the broken one, which can then be fixed or removed later if it turns out to be problematic to other people. Really, can you stop being aggressive? You haven't proved that test is wrong, and it passes consistently fine on all buildbots. If you don't agree with what is being tested, that's another matter. But please accept that the test is ok w.r.t. Condition's specified behaviour. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8799 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14098] provide public C-API for reading/setting sys.exc_info()
Stefan Behnel sco...@users.sourceforge.net added the comment: Done. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14098 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13165] Integrate stringbench in the Tools directory
Serhiy Storchaka storch...@gmail.com added the comment: Please open a new issue for such improvement. Well, I'll do it as soon as slightly improve the script. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13165 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12978] Figure out extended attributes on BSDs
Changes by Hynek Schlawack h...@ox.cx: -- nosy: +hynek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12978 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8799] Hang in lib/test/test_threading.py
Antoine Pitrou pit...@free.fr added the comment: I'm proposing the following changes to the threading docs. Most of them are cleanups and small improvements, but I also rewrote the offending paragraph, and made the wait_for example more proeminent. -- Added file: http://bugs.python.org/file25170/tpconditiondoc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8799 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10484] http.server.is_cgi fails to handle CGI URLs containing PATH_INFO
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 89eeaa18700f by Senthil Kumaran in branch '2.7': fix the incorrect changes made for PATH_INFO value - Issue10484 http://hg.python.org/cpython/rev/89eeaa18700f New changeset 827a4062b1d6 by Senthil Kumaran in branch '3.2': 3.2- fix the incorrect changes made for PATH_INFO value - Issue10484 http://hg.python.org/cpython/rev/827a4062b1d6 New changeset 8bcc5768bc05 by Senthil Kumaran in branch 'default': merge - fix the incorrect changes made for PATH_INFO value - Issue10484 http://hg.python.org/cpython/rev/8bcc5768bc05 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14258] Better explain re.LOCALE and re.UNICODE for \S and \W
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 4d49a2415ced by Senthil Kumaran in branch '2.7': Fix closes Issue14258 - Clarify the re.LOCALE and re.UNICODE flags for \S class http://hg.python.org/cpython/rev/4d49a2415ced -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14258 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10484] http.server.is_cgi fails to handle CGI URLs containing PATH_INFO
Senthil Kumaran sent...@uthcode.com added the comment: I had to carefully review a lot of changes for this. In addition, I did setup a apache and tested the behaviors too. Few notes - - The test for _url_collapse_path_split is not directly helpful, especially for PATH_INFO. I removed my previous changes I had made as I think, it is a mistake to test PATH_INFO in there. - There is not a test for path_info, it should be added. I could test only on local apache setup. - Coming the changes itself, the previous _url_collapse_path_split was just fine for what it is supposed to do. Return head and tail for certain definitions of parsing (removing . and .. and tail is last part and rest is head). - I incorporated Glenn Linderman logic in is_cgi to have explicit head and tail. Glenn's comment and cgi directories could overridden is important and in that ascept the previous commit had to be changed. I also looked at changes in the patches contained in issue 13893, but I found that those broke behavior or exhibited the security issue again. taking care of all these, I have the made the changes to the cgi module and also verified pratically that PATH_INFO is indeed sent correctly. Ran python -m CGIHttpServer and placed cgi-bin/file1.py and sent some requests to verify PATH_INFO. The values were proper. With this, I think this issue can be closed. The rest of the cgi changes can be handled in their respective issues. A test to PATH_INFO could just be added. -- Added file: http://bugs.python.org/file25171/file1.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8799] Hang in lib/test/test_threading.py
Charles-François Natali neolo...@free.fr added the comment: I'm proposing the following changes to the threading docs. Most of them are cleanups and small improvements, but I also rewrote the offending paragraph, and made the wait_for example more proeminent. Looks good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8799 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14532] multiprocessing module performs a time-dependent hmac comparison
Charles-François Natali neolo...@free.fr added the comment: Therefore the expected digest changes each time. Exactly. Timing attacks (which aren't really new :-) depend on a constant digest to successively determine the characters composing the digest. Here, that won't work, because the digest changes every time. -- nosy: +neologix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14532 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14540] Crash in Modules/_ctypes/libffi/src/dlmalloc.c on ia64-hp-hpux11.31
Charles-François Natali neolo...@free.fr added the comment: This stack trace is strange. Is it really the python binary? Anyway, if it's segfaulting inside dlmalloc, there's probably not much we can do. Actually, I wonder why we still ship it... -- nosy: +neologix, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14540 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14423] Getting the starting date of iso week from a week number and a year.
Esben Agerbæk Black esbe...@gmail.com added the comment: 1) Yes I agree, your solution is somewhat more concise, I have corrected the code accordingly. 2) I get errors for all my test when I build my python and run ./python.exe -m test.datetimetester -j3 I asume this is because I have yet to implement the c version in Modules/_datetimemodule.c is this the correct assumption? Kind regards On Tue, Apr 10, 2012 at 3:32 PM, Alexander Belopolsky rep...@bugs.python.org wrote: Alexander Belopolsky alexander.belopol...@gmail.com added the comment: On Tue, Apr 10, 2012 at 6:44 AM, Antoine Pitrou rep...@bugs.python.org wrote: It's so easy that the patch isn't a one-liner and it seems to still have bugs wrt. intended behaviour. Unless I miss something, the inverse to isocalendar() is simply from datetime import * def fromiso(year, week, day): d = date(year, 1, 4) return d + timedelta((week - 1) * 7 + day - d.isoweekday()) At least it works in my testing: (2012, 15, 2) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14423 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14423 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8799] Hang in lib/test/test_threading.py
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 2f51dca92883 by Antoine Pitrou in branch '3.2': Issue #8799: Fix and improve the threading.Condition documentation. http://hg.python.org/cpython/rev/2f51dca92883 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8799 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14423] Getting the starting date of iso week from a week number and a year.
Antoine Pitrou pit...@free.fr added the comment: 1) Yes I agree, your solution is somewhat more concise, I have corrected the code accordingly. 2) I get errors for all my test when I build my python and run ./python.exe -m test.datetimetester -j3 I asume this is because I have yet to implement the c version in Modules/_datetimemodule.c is this the correct assumption? You should probably run ./python.exe -m test -v test_datetime instead. Not sure that will fix your test failures, though :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14423 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8799] Hang in lib/test/test_threading.py
Antoine Pitrou pit...@free.fr added the comment: Ok, I've fixed the docs in 3.2 and 3.3. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8799 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14540] Crash in Modules/_ctypes/libffi/src/dlmalloc.c on ia64-hp-hpux11.31
Antoine Pitrou pit...@free.fr added the comment: Anyway, if it's segfaulting inside dlmalloc, there's probably not much we can do. Actually, I wonder why we still ship it... I think it's bundled with our copy of libffi. I agree the stacktrace is strange. At the very least it looks truncated. Also it looks like our dlmalloc has shadowed the built-in malloc, which would be quite disturbing. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14540 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14542] reverse() doesn't reverse sort correctly
New submission from Bill Jefferson shagge...@yahoo.com: reverse() doesn't reverse sort correctly in Python 25 and 27. sort() works correctly, but reverse doesn't. The following uses reverse(). Incorrect. Even though the date comes first, reverse() sorts on the file name, B57IBMCD_T.zip 2012-04-05 B57IBMCD_T7.2.3.1.zip 2012-03-23 B57IBMCD_T7.2.2.3.zip 2012-02-22 B57IBMCD_T7.2.2.2.zip 2012-02-13 B57IBMCD_T7.2.2.1.zip 2012-01-23 B57IBMCD_T7.2.1.1.zip 2012-03-28 B57IBMCD_T7.0.4.6.zip 2012-03-08 B57IBMCD_T7.0.4.5.zip 2012-03-03 B57IBMCD_T7.0.4.4.zip 2012-02-29 B57IBMCD_T7.0.4.3.zip 2012-01-06 B57IBMCD_T7.0.4.2.zip 2011-12-08 B57IBMCD_T7.0.4.1.zip 2012-01-06 B57IBMCD_T7.0.3.1.zip 2012-01-06 B57IBMCD_T7.0.2.2.zip 2012-01-06 B57IBMCD_T7.0.2.1.zip 2012-01-06 B57IBMCD_T6.2.4.9.zip 2011-12-07 B57IBMCD_T6.2.4.9-r1.zip 2011-09-13 B57IBMCD_T6.2.4.8.zip 2012-03-28 B57IBMCD_T6.2.4.12.zip 2012-02-15 B57IBMCD_T6.2.4.11.zip 2011-12-06 B57IBMCD_T6.2.4.10.zip -- components: Demos and Tools, IDLE, Windows files: EX38.PY messages: 157988 nosy: billje priority: normal severity: normal status: open title: reverse() doesn't reverse sort correctly type: performance versions: Python 2.7 Added file: http://bugs.python.org/file25172/EX38.PY ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14428] Implementation of the PEP 418
STINNER Victor victor.stin...@gmail.com added the comment:
+if (has_getickcount64) {
+ULONGLONG ticks;
+ticks = Py_GetTickCount64();
+result = (double)ticks * 1e-3
+}
; is missing after 1e-3, it does not compile on Windows because of this.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14428
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14542] reverse() doesn't reverse sort correctly
Eric V. Smith e...@trueblade.com added the comment: list.reverse() does not reverse a list, it reverses its current values. help([].reverse) Help on built-in function reverse: reverse(...) L.reverse() -- reverse *IN PLACE* -- nosy: +eric.smith resolution: - invalid stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14478] Decimal hashing very slow, could be cached
Raymond Hettinger raymond.hettin...@gmail.com added the comment: I don't see a need to cache the hash value in the pure Python version. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14478 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14539] logging module: logger does not print log message with logging.INFO level
zodalahtathi m8r-a70...@mailinator.com added the comment: Thank you for the explanation -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14539 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14341] sporadic (?) test_urllib2 failures
Stefan Krah stefan-use...@bytereef.org added the comment: How about silencing the AssertionError until a better solution is found? The patch works here. -- keywords: +patch Added file: http://bugs.python.org/file25173/issue14341.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14341 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14341] sporadic (?) test_urllib2 failures
Antoine Pitrou pit...@free.fr added the comment: Well, the point of the test is to check that the warnings are issued, so silencing them kind of defeats it. Senthil, why did you use check_warning instead of assertWarns? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14341 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14543] Upgrade OpenSSL on Windows to 0.9.8u
New submission from Dino Viehland di...@microsoft.com: OpenSSL has had many fixes since the 0.9.8l version, and in particular there is one issue which prevents it from connecting with SSL with a client certificate: the end result is the SSL connection hangs or times out. Updating the OpenSSL version will fix this and enable better compatibility across platforms. I've attached my repro but if you want to try it you'll need a different server + private key pair to authenticate with. I've also confirmed re-building Python with 0.9.8m fixes the problem and Python currently ships with 0.9.8l. -- components: Extension Modules files: repro.py messages: 157995 nosy: benjamin.peterson, dino.viehland priority: release blocker severity: normal status: open title: Upgrade OpenSSL on Windows to 0.9.8u type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file25174/repro.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14543 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14543] Upgrade OpenSSL on Windows to 0.9.8u
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14543 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14543] Upgrade OpenSSL on Windows to 0.9.8u
STINNER Victor victor.stin...@gmail.com added the comment: Why not upgrading to OpenSSL 1.0, at least for Python 3.3? -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14543 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14543] Upgrade OpenSSL on Windows to 0.9.8u
Antoine Pitrou pit...@free.fr added the comment: Well, 3.3 already links with openssl-1.0.0a. However, updating to the latest 1.0.x would probably be good. -- nosy: +georg.brandl versions: +Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14543 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14543] Upgrade OpenSSL on Windows to 0.9.8u
Dino Viehland di...@microsoft.com added the comment: A 1.0 version would be fine w/ me (I tested it with one of those and it worked as well) - I was just thinking a bug fix release might want to stick w/ a bug fix release of OpenSSL too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14543 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14543] Upgrade OpenSSL on Windows to 0.9.8u
Antoine Pitrou pit...@free.fr added the comment: A 1.0 version would be fine w/ me (I tested it with one of those and it worked as well) - I was just thinking a bug fix release might want to stick w/ a bug fix release of OpenSSL too. Agreed, I was replying to Victor about 3.3. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14543 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10484] http.server.is_cgi fails to handle CGI URLs containing PATH_INFO
Glenn Linderman v+pyt...@g.nevcal.com added the comment: Senthil, thanks for your work on this. Regarding: I also looked at changes in the patches contained in issue 13893, but I found that those broke behavior or exhibited the security issue again. I'd be curious to know what problems you discovered, since I had hoped I had fixed them all (and know I fixed enough to work in my environment). I'll review your code in the next while, and attempt to include it in mine, and test it in my environment... I really don't want to maintain my own code, but do need functional code... hopefully once the other issues are fixed I can just use released code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2377] Replace __import__ w/ importlib.__import__
Brett Cannon br...@python.org added the comment: OK, I have fixed test_trace by tweaking the trace module in default. I have decided to follow Antoine's suggestion-by-question and get test_pydoc working before I merge by getting ImportError spruced up in default but pydoc changed in bootstrap_importlib. I am *not* going to try to get registry-based imports working because I don't have a Windows machine and could quite easily break the build. I would rather have a Windows expert add the support. IOW: * Issue #1559549 * Fix pydoc in bootstrap_importlib * Big patch merged into default * ??? * Profit! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2377 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2377] Replace __import__ w/ importlib.__import__
Changes by Brett Cannon br...@python.org: -- dependencies: +ImportError needs attributes for module and file name ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2377 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1559549] ImportError needs attributes for module and file name
Brett Cannon br...@python.org added the comment: This is now officially blocking my importlib bootstrap work (issue #2377), so I have assigned this to myself to get done and I hope to get this committed within a week *without* updating Python/import.c and the requisite tests or pydoc (which I will make part of my merge instead). If Brian beats me to getting this checked in that's great, but otherwise I will get to it myself. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1559549 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14540] Crash in Modules/_ctypes/libffi/src/dlmalloc.c on ia64-hp-hpux11.31
Paul A. p...@freeshell.org added the comment: I'd be more than happy to use my own installation of libffi instead, but it seems the --with-system-ffi configure flag doesn't work. I've also opened a different bug for that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14540 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14527] How to link with an external libffi?
Paul A. p...@freeshell.org added the comment: While this is no solution by any means, I think it'd be better for the scenario to be a fatal configure error. After all, if I say --with-system-ffi, it means I really, really want want to use my own libffi. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14527 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14544] Limit global keyword name conflicts in language spec to those enforced by CPython
New submission from Nick Coghlan ncogh...@gmail.com: The language spec currently includes the following paragraph [1]: Names listed in a global statement must not be defined as formal parameters or in a for loop control target, class definition, function definition, or import statement. While the first restriction is real (and enforced by CPython), since formal parameters are explicitly defined as local variables, there's no obvious rationale for the last 4 restrictions (and CPython doesn't enforce any of them). The proposal is that the paragraph be simplified to: Names listed in a global statement must not also be defined as formal function parameters. Attempting to do so raises SyntaxError. The current (incorrect!) CPython implementation detail note will be removed. A similar clarification will also be made in the nonlocal statement documentation. [1] http://docs.python.org/dev/reference/simple_stmts.html#the-global-statement -- messages: 158005 nosy: ncoghlan priority: normal severity: normal status: open title: Limit global keyword name conflicts in language spec to those enforced by CPython type: enhancement versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14544 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14544] Limit global keyword name conflicts in language spec to those enforced by CPython
Alex Gaynor alex.gay...@gmail.com added the comment: This shouldn't be a problem for PyPy, in fact I'm almost positive that we implement this already (since Django has a test that uses this feature). If/when the spec is changed please make sure there are tests for all these cases so we *know* it works though. -- nosy: +alex ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14544 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14544] Limit global keyword name conflicts in language spec to those enforced by CPython
Nick Coghlan ncogh...@gmail.com added the comment: Thread link: http://mail.python.org/pipermail/python-ideas/2012-April/014783.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14544 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14544] Limit global keyword name conflicts in language spec to those enforced by CPython
Changes by Éric Araujo mer...@netwok.org: -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14544 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14545] html module should not be available in Python 3.1
New submission from Chris Jerdonek chris.jerdo...@gmail.com: The Python documentation says that the html module (defining html.escape()) is new in Python 3.2: http://docs.python.org/dev/library/html.html However, it's importable in Python 3.1, but without the escape() function. See below for evidence. This prevents the usual EAFP code from not working: try: # Python 3.2 deprecates cgi.escape() and adds the html module as a replacement. import html except ImportError: import cgi as html python Python 3.1.4 (default, Apr 10 2012, 21:58:25) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type help, copyright, credits or license for more information. import html html.escape Traceback (most recent call last): File stdin, line 1, in module AttributeError: 'module' object has no attribute 'escape' dir(html) ['__builtins__', '__doc__', '__file__', '__name__', '__package__', '__path__'] html.__file__ '/opt/local/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/html/__init__.py' -- components: None messages: 158008 nosy: cjerdonek priority: normal severity: normal status: open title: html module should not be available in Python 3.1 type: behavior versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14545 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14544] Limit global keyword name conflicts in language spec to those enforced by CPython
Changes by Chris Rebert pyb...@rebertia.com: -- nosy: +cvrebert ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14544 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
