[issue44787] Missing valid directive %D in datetime.strftime() documentation
Raphael added the comment: Perhaps it could be mentioned more clearly in the datetime documentation that apart from the directives of the C89 standard, you can also use those that the underlying libc strftime() supports. The following sentence from https://docs.python.org/3/library/time.html#time.strftime describes it well in my opinion: "Additional directives may be supported on certain platforms, but only the ones listed here have a meaning standardized by ANSI C." Perhaps a reference to "man strftime" would also be helpful. -- nosy: +Raphael ___ Python tracker <https://bugs.python.org/issue44787> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45599] Please official support %G, %V and %u directives in time library
New submission from Raphael :
In the time library documentation (https://docs.python.org/3/library/time.html)
the directives %G, %V and %u for strftime() are missing, although they work (at
least for me in Linux Mint):
$ python3
Python 3.8.10 (default, Sep 28 2021, 16:10:42)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from time import strftime
>>> strftime("%G-W%V-%u")
'2021-W42-7'
This seems to be officially supported by the datetime library since
https://bugs.python.org/issue12006 or at least there is a section for the ISO
8601 week directives in the datetime documentation:
https://docs.python.org/3/library/datetime.html#strftime-and-strptime-format-codes
I would like to see the same for the time library.
--
components: Library (Lib)
messages: 404933
nosy: Raphael
priority: normal
severity: normal
status: open
title: Please official support %G, %V and %u directives in time library
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python
3.9
___
Python tracker
<https://bugs.python.org/issue45599>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45599] Please officially support %G, %V and %u directives in time library
Change by Raphael : -- title: Please official support %G, %V and %u directives in time library -> Please officially support %G, %V and %u directives in time library ___ Python tracker <https://bugs.python.org/issue45599> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9874] Message.attach() loses empty attachments
New submission from Raphael Mankin : When attaching a sequence of parts to a MIMEMultipart message, empty attachments are silently discarded. -- components: Library (Lib) messages: 116550 nosy: r...@mankin.org.uk priority: normal severity: normal status: open title: Message.attach() loses empty attachments type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue9874> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9874] Message.attach() loses empty attachments
Raphael Mankin added the comment: 'Simple' is the problem. I will come back to you on this. -- ___ Python tracker <http://bugs.python.org/issue9874> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10452] Unhelpful diagnostic 'cannot find the path specified'
New submission from Raphael Mankin : Something somewhere in the library issues the diagnostic 'The system cannot find the path specified' with no indication of what path it was looking for nor where the error was detected. The relevant routine needs modification to print at least the path and preferably also a back-trace. -- components: Library (Lib) messages: 121453 nosy: r...@mankin.org.uk priority: normal severity: normal status: open title: Unhelpful diagnostic 'cannot find the path specified' versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue10452> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3028] tokenize module: normal lines, not "logical"
New submission from Noam Raphael <[EMAIL PROTECTED]>: Hello, The documentation of the tokenize module says: "The line passed is the *logical* line; continuation lines are included." Some background: The tokenize module splits a python source into tokens, and says for each token where it begins and where it ends, in the format of (row, offset). This note in the documentation made me think that continuation lines are considered as one line, and made me break my head how I should find the offset of the token in the original string. The truth is that the row number is simply the index of the line as returned by the readline function, and it's very simple to reconstruct the string offset. I suggest that this will be changed to something like "The line passed is the index of the string returned by the readline function, plus 1. That is, the first string returned is called line 1, the second is called line 2, and so on." Thanks, Noam -- assignee: georg.brandl components: Documentation messages: 67635 nosy: georg.brandl, noam severity: normal status: open title: tokenize module: normal lines, not "logical" versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3028> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3028] tokenize module: normal lines, not "logical"
Noam Raphael <[EMAIL PROTECTED]> added the comment: Can I suggest that you also add something like "The row indices in the (row, column) tuples, however, are physical, and don't treat continuation lines specially."? It's just that it took me some time to understand your clarification, since the row indices I thought the documentation talks about are also tuple items, they just happen to be the first in the tuple, not the last. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3028> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8048] doctest assumes sys.displayhook hasn't been touched
New submission from Noam Raphael : Hello, This bug is the cause of a bug reported about DreamPie: https://bugs.launchpad.net/bugs/530969 DreamPie (http://dreampie.sourceforge.net) changes sys.displayhook so that values will be sent to the parent process instead of being printed in stdout. This causes doctest to fail when run from DreamPie, because it implicitly assumes that sys.displayhook writes the values it gets to sys.stdout. This is why doctest replaces sys.stdout with its own file-like object, which is ready to receive the printed values. The solution is simply to replace sys.displayhook with a function that will do the expected thing, just like sys.stdout is replaced. The patch I attach does exactly this. Thanks, Noam -- components: Library (Lib) files: doctest.py.diff keywords: patch messages: 100334 nosy: noam severity: normal status: open title: doctest assumes sys.displayhook hasn't been touched type: behavior Added file: http://bugs.python.org/file16421/doctest.py.diff ___ Python tracker <http://bugs.python.org/issue8048> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Noam Raphael added the comment: I don't know, for me it works fine, even after downloading a fresh SVN copy. On what platform does it happen? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1580> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Noam Raphael added the comment: I also use linux on x86. I think that byte order would cause different results (the repr of a random float shouldn't be "1.0".) Does the test case run ok? Because if it does, it's really strange. -- versions: -Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1580> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Noam Raphael added the comment: Oh, this is sad. Now I know why Tcl have implemented also a decimal to binary routine. Perhaps we can simply use both their routines? If I am not mistaken, their only real dependency is on a library which allows arbitrary long integers, called tommath, from which they use a few basic functions. We can use instead the functions from longobject.c. It will probably be somewhat slower, since longobject.c wasn't created to allow in-place operations, but I don't think it should be that bad -- we are mostly talking about compile time. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1580> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Noam Raphael added the comment: The Tcl code can be fonund here: http://tcl.cvs.sourceforge.net/tcl/tcl/generic/tclStrToD.c?view=markup What Tim says gives another reason for using that code - it means that currently, the compilation of the same source code on two platforms can result in a code which does different things. Just to make sure - IEEE does require that operations on doubles will do the same thing on different platforms, right? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1580> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Noam Raphael added the comment: I think that for str(), the current method is better - using the new repr() method will make str(1.1*3) == '3.3003', instead of '3.3'. (The repr is right - you can check, and 1.1*3 != 3.3. But for str() purposes it's fine.) But I actually think that we should also use Tcl's decimal to binary conversion - otherwise, a .pyc file created by python compiled with Microsoft will cause a different behaviour from a .pyc file created by python compiled with Gnu, which is quite strange. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1580> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Noam Raphael added the comment: If I think about it some more, why not get rid of all the float platform-dependencies and define how +inf, -inf and nan behave? I think that it means: * inf and -inf are legitimate floats just like any other float. Perhaps there should be a builtin Inf, or at least math.inf. * nan is an object of type float, which behaves like None, that is: "nan == nan" is true, but "nan < nan" and "nan < 3" will raise an exception. Mathematical operations which used to return nan will raise an exception (division by zero does this already, but "inf + -inf" will do that too, instead of returning nan.) Again, there should be a builtin NaN, or math.nan. The reason for having a special nan object is compatibility with IEEE floats - I want to be able to pass around IEEE floats easily even if they happen to be nan. This is basically what Tcl did, if I understand correctly - see item 6 in http://www.tcl.tk/cgi-bin/tct/tip/132.html . __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1580> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Noam Raphael added the comment: That's right, but the standard also defines that 0.0/0 -> nan, and 1.0/0 -> inf, but instead we raise an exception. It's just that in Python, every object is expected to be equal to itself. Otherwise, how can I check if a number is nan? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1580> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Noam Raphael added the comment: If I understand correctly, there are two main concerns: speed and portability. I think that they are both not that terrible. How about this: * For IEEE-754 hardware, we implement decimal/binary conversions, and define the exact behaviour of floats. * For non-IEEE-754 hardware, we keep the current method of relying on the system libraries. About speed, perhaps it's not such a big problem, since decimal/binary conversions are usually related to I/O, and this is relatively slow anyway. I think that usually a program does a relatively few decimal/binary conversions. About portability, I think (from a small research I just made) that S90 supports IEEE-754. This leaves VAX and cray users, which will have to live with a non-perfect floating-point behaviour. If I am correct, it will let 99.9% of the users get a deterministic floating-point behaviour, where eval(repr(f)) == f and repr(1.1)=='1.1', with a speed penalty they won't notice. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1580> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Noam Raphael added the comment: If I were in that situation I would prefer to store the binary representation. But if someone really needs to store decimal floats, we can add a method "fast_repr" which always calculates 17 decimal digits. Decimal to binary conversion, in any case, shouldn't be slower than it is now, since on Gnu it is done anyway, and I don't think that our implementation should be much slower. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1580> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Noam Raphael added the comment: Ok, so if I understand correctly, the ideal thing would be to implement decimal to binary conversion by ourselves. This would make str <-> float conversion do the same thing on all platforms, and would make repr(1.1)=='1.1'. This would also allow us to define exactly how floats operate, with regard to infinities and NaNs. All this is for IEEE-754 platforms -- for the rare platforms which don't support it, the current state remains. However, I don't think I'm going, in the near future, to add a decimal to binary implementation -- the Tcl code looks very nice, but it's quite complicated and I don't want to fiddle with it right now. If nobody is going to implement the correctly rounding decimal to binary conversion, then I see three options: 1. Revert to previous situation 2. Keep the binary to shortest decimal routine and use it only when we know that the system's decimal to binary routine is correctly rounding (we can check - perhaps Microsoft has changed theirs?) 3. Keep the binary to shortest decimal routine and drop repr(f) == f (I don't like that option). If options 2 or 3 are chosen, we can check the 1e5 bug. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1580> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Noam Raphael added the comment: 2007/12/13, Guido van Rossum <[EMAIL PROTECTED]>: > > > Ok, so if I understand correctly, the ideal thing would be to > > implement decimal to binary conversion by ourselves. This would make > > str <-> float conversion do the same thing on all platforms, and would > > make repr(1.1)=='1.1'. This would also allow us to define exactly how > > floats operate, with regard to infinities and NaNs. All this is for > > IEEE-754 platforms -- for the rare platforms which don't support it, > > the current state remains. > > Does doubledigits.c not work for non-754 platforms? No. It may be a kind of an oops, but currently it just won't compile on platforms which it doesn't recognize, and it only recognizes 754 platforms. > > > 2. Keep the binary to shortest decimal routine and use it only when we > > know that the system's decimal to binary routine is correctly rounding > > (we can check - perhaps Microsoft has changed theirs?) > > Tim says you can't check (test) for this -- you have to prove it from > source, or trust the vendor's documentation. I would have no idea > where to find this documented. > The program for testing floating point compatibility is in http://www.cant.ua.ac.be/ieeecc754.html To run it, on my computer, I used: ./configure -target Conversions -platform IntelPentium_cpp make ./IeeeCC754 -d -r n -n x Conversion/testsets/d2bconvd less ieee.log This tests only doubles, round to nearest, and ignores flags which should be raised to signal inexact conversion. You can use any file in Conversions/testsets/d2b* - I chose this one pretty randomly. It turns out that even on my gcc 4.1.3 it finds a few floats not correctly rounded. :( Anyway, it can be used to test other platforms. If not by the executable itself, we can pretty easily write a python program which uses the test data. I don't know what exactly the errors with gcc 4.1.3 mean - is there a problem with the algorithm of glibc, or perhaps the testing program didn't set some flag? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1580> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Noam Raphael added the comment: Ok, I think I have a solution! We don't really need always the shortest decimal representation. We just want that for most floats which have a nice decimal representation, that representation will be used. Why not do something like that: def newrepr(f): r = str(f) if eval(r) == f: return r else: return repr(f) Or, in more words: 1. Calculate the decimal representation of f with 17 precision digits, s1, using the system's routines. 2. Create a new string, s2, by rounding the resulting string to 12 precision digits. 3. Convert the resulting rounded string to a new double, g, using the system's routines. 4. If f==g, return s2. Otherwise, return s1. It will take some more time than the current repr(), because of the additional decimal to binary conversion, but we already said that if speed is extremely important one can use "'%f.17' % f". It will obviously preserve the eval(repr(f)) == f property. And it will return a short representation for almost any float that has a short representation. This algorithm I will be glad to implement. What do you think? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1580> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Noam Raphael added the comment: I think that we can give up float(repr(x)) == x across different platforms, since we don't guarantee something more basic: We don't guarantee that the same program doing only floating point operations will produce the same results across different 754 platforms, because in the compilation process we rely on the system's decimal to binary conversion. In other words, using the current repr(), one can pass a value x from platform A platform B and be sure to get the same value. But if he has a python function f, he can't be sure that f(x) on platform A will result in the same value as f(x) on platform B. So the cross-platform repr() doesn't really matter. I like eval(repr(x)) == x because it means that repr(x) captures all the information about x, not because it lets me pass x from one platform to another. For communication, I use other methods. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1580> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Noam Raphael added the comment: 2007/12/18, Raymond Hettinger <[EMAIL PROTECTED]>: > The 17 digit representation is useful in that it suggests where the > problem lies. In contrast, showing two numbers with reprs of different > lengths will strongly suggest that the shorter one is exactly > represented. Currently, that is a useful suggestion, 10.25 shows as > 10.25 while 10.21 shows as 10.211 (indicating that the > latter is not exactly represented). If you start showing 1.1 as 1.1, > then you've lost both benefits. Currently, repr(1.3) == '1.3', suggesting that it is exactly represented, which isn't true. I think that unless you use an algorithm that will truncate zeros only if the decimal representation is exact, the suggested algorithm is less confusing than the current one, in that it doesn't suggest that 1.3 is exactly stored and 1.1 isn't. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1580> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Noam Raphael added the comment: About the educational problem. If someone is puzzled by "1.1*3 != 3.3", you could always use '%50f' % 1.1 instead of repr(1.1). I don't think that trying to teach people that floating points don't always do what they expect them to do is a good reason to print uninteresting and visually distracting digits when you don't have to. About the compatibility problem: I don't see why it should matter to the NumPy people if the repr() of some floats is made shorter. Anyway, we can ask them, using a PEP or just the mailing list. About the benefit: If I have data which contains floats, I'm usually interested about their (physical) value, not about their last bits. That's why str(f) does what it does. I like repr(x) to be one-to-one, as I explained in the previous message, but if it can be made more readable, why not make it so? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1580> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue979658] Improve HTML documentation of a directory
Noam Raphael added the comment: I just wanted to say that I'm not going to bother too much with this right now - Personally I will just use epydoc when I want to create an HTML documentation. Of course, you can still do whatever you like with the patch. Good luck, Noam -- nosy: +noam Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue979658> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38886] permissions too restrictive in zipfile.writestr
New submission from Raphael Dussin : zipfile.writestr write with permissions 600 by default and there is no way to override permissions. This can be an issue when writing zip archive of data one want to share (e.g. zarr zipstore, see https://github.com/zarr-developers/zarr-python/pull/517) Proposed fix in upcoming PR is to add the desired permission as an optional arg. -- components: Library (Lib) messages: 357210 nosy: rdussin priority: normal severity: normal status: open title: permissions too restrictive in zipfile.writestr type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue38886> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38886] permissions too restrictive in zipfile.writestr
Change by Raphael Dussin : -- keywords: +patch pull_requests: +16814 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17327 ___ Python tracker <https://bugs.python.org/issue38886> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41550] SimpleQueues put blocks if feeded with strings greater than 2**16-13 chars
New submission from Raphael Grewe : Hi at all, Maybe I am using the put function incorrectly, but it is not possible to add larger strings there. The programm keeps locked and is doing nothing. I tested it on latest Debian Buster. Python 3.7.3 (default, Jul 25 2020, 13:03:44) Please check the example script. python3 test_simple_queue_put.py 2**16-13 -- files: test_simple_queue_put.py messages: 375385 nosy: rgrewe priority: normal severity: normal status: open title: SimpleQueues put blocks if feeded with strings greater than 2**16-13 chars versions: Python 3.7 Added file: https://bugs.python.org/file49389/test_simple_queue_put.py ___ Python tracker <https://bugs.python.org/issue41550> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41550] SimpleQueues put blocks if feeded with strings greater than 2**16-13 chars
Raphael Grewe added the comment: I used SimpleQueue on purpose because I only need the functions get and put. Of course I could also use Queue but that would be just a workaround for me. -- ___ Python tracker <https://bugs.python.org/issue41550> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41550] SimpleQueues put blocks if feeded with strings greater than 2**16-13 chars
Raphael Grewe added the comment: Soo... I think I use the functions indeed incorrectly then. Thank you for your time. Regards Raphael -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue41550> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31270] Simplify documentation of itertools.zip_longest
Changes by Raphael Michel : -- pull_requests: +3239 ___ Python tracker <http://bugs.python.org/issue31270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31270] Simplify documentation of itertools.zip_longest
New submission from Raphael Michel:
The documentation given for itertools.zip_longest contains a "roughly
equivalent" pure-python implementation of the function that is intended to help
the user understand what zip_longest does on a functional level.
However, the given implementation is very complicated to read for newcomers and
experienced Python programmers alike, as it uses a custom-defined exception for
control flow handling, a nested function, a condition that always is true if
any arguments are passed ("while iterators"), as well as two other non-trivial
functions from itertools (chain and repeat).
For future reference, this is the currently given implementation:
def zip_longest(*args, **kwds):
# zip_longest('ABCD', 'xy', fillvalue='-') --> Ax By C- D-
fillvalue = kwds.get('fillvalue')
iterators = [iter(it) for it in args]
while True:
exhausted = 0
values = []
for it in iterators:
try:
values.append(next(it))
except StopIteration:
values.append(fillvalue)
exhausted += 1
if exhausted < len(args):
yield tuple(values)
else:
break
This is way more complex than necessary to teach the concept of zip_longest.
With this issue, I will submit a pull request with a new example implementation
that seems to be the same level of "roughly equivalent" but is much easier to
read, since it only uses two loops and now complicated flow
def zip_longest(*args, **kwds):
# zip_longest('ABCD', 'xy', fillvalue='-') --> Ax By C- D-
fillvalue = kwds.get('fillvalue')
iterators = [iter(it) for it in args]
while True:
exhausted = 0
values = []
for it in iterators:
try:
values.append(next(it))
except StopIteration:
values.append(fillvalue)
exhausted += 1
if exhausted < len(args):
yield tuple(values)
else:
break
Looking at the C code of the actual implementation, I don't see that any one of
the two implementations is obviously "more equivalent". I'm unsure about
performance -- I haven't tried them on that but I don't think that's the point
of this learning implementation.
I ran all tests from Lib/test/test_itertools.py against both the old and the
new implementation. The new implementation fails at 3 tests, while the old
implementation failed at four. Two of the remaining failures are related to
TypeErrors not being thrown on invalid input, one of them is related to
pickling the resulting object. I believe all three of them are fine to ignore
in this sample, as it is not relevant to the documentation purpose.
Therefore, I believe the documentation should be changed like suggested. I'd be
happy for any feedback or further ideas to improve its readability!
--
assignee: docs@python
components: Documentation
messages: 300788
nosy: docs@python, rami
priority: normal
severity: normal
status: open
title: Simplify documentation of itertools.zip_longest
type: enhancement
versions: Python 3.7
___
Python tracker
<http://bugs.python.org/issue31270>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31270] Simplify documentation of itertools.zip_longest
Raphael Michel added the comment:
I just noticed that in my post I accidentally pasted MY implementation twice
instead of the old one, sorry for that. Here's the old one for quick comparison:
class ZipExhausted(Exception):
pass
def zip_longest(*args, **kwds):
# zip_longest('ABCD', 'xy', fillvalue='-') --> Ax By C- D-
fillvalue = kwds.get('fillvalue')
counter = len(args) - 1
def sentinel():
nonlocal counter
if not counter:
raise ZipExhausted
counter -= 1
yield fillvalue
fillers = repeat(fillvalue)
iterators = [chain(it, sentinel(), fillers) for it in args]
try:
while iterators:
yield tuple(map(next, iterators))
except ZipExhausted:
pass
--
___
Python tracker
<http://bugs.python.org/issue31270>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31270] Simplify documentation of itertools.zip_longest
Raphael Michel added the comment:
Well, I could think of a way to still use repeat() here that also is pretty
clean except for the fact that it fails if all inputs to zip_longest are
repeat() iterators themselves (which would here lead to an empty iterator while
it would otherwise lead to an infinite one):
def zip_longest(*args, **kwds):
# zip_longest('ABCD', 'xy', fillvalue='-') --> Ax By C- D-
fillvalue = kwds.get('fillvalue')
iterators = [iter(it) for it in args]
while True:
values = []
for i, it in enumerate(iterators):
try:
values.append(next(it))
except StopIteration:
values.append(fillvalue)
iterators[i] = repeat(fillvalue)
if all(isinstance(it, repeat) for it in iterators):
break
else:
yield tuple(values)
Keeping chain() in use here just for the sake of using it is not worth it, I
believe.
--
___
Python tracker
<http://bugs.python.org/issue31270>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27240] 'UnstructuredTokenList' object has no attribute '_fold_as_ew'
Raphael Slinckx added the comment: It happens regularly for emails with long header lines for me too, which makes the python3 email module quite unusable. A workaround which seems to help a bit is to set refold_source='none' on the email policy, although it seems to keep happening, less often. Is the fix proposed by Emmanuel a proper fix ? I'm not knowledgeable enough on this subject... -- nosy: +rslinckx ___ Python tracker <http://bugs.python.org/issue27240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29856] curses online documentation typo
New submission from Raphael McSinyx: I think there is a typo in curses online documentation about key constants: https://docs.python.org/3.7/library/curses.html#constants The key KEY_SEXIT is described as `Shifted Dxit' while I think that should be `Shifted Exit'. -- assignee: docs@python components: Documentation messages: 289868 nosy: McSinyx, docs@python priority: normal severity: normal status: open title: curses online documentation typo versions: Python 3.7 ___ Python tracker <http://bugs.python.org/issue29856> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29989] subprocess.Popen does not handle file-like objects without file descriptors
New submission from Raphael Gaschignard: >From the documentation of the io module: fileno() Return the underlying file descriptor (an integer) of the stream if it exists. An OSError is raised if the IO object does not use a file descriptor. However, when passing a file-like object without a file descriptor (that raises OSError when calling f.fileno()) to POpen (for stdout, for example), the raised exception is not handled properly. (However, on inspection of subprocess code, returning -1 will cause the code to handle this properly) I'm not sure whether this is an issue in the io module documentation or in the subprocess code. the core issue seems to be in POpen.get_handles, that seems to expect that -1 is used to signal "no file descriptor available". -- messages: 291151 nosy: rtpg priority: normal severity: normal status: open title: subprocess.Popen does not handle file-like objects without file descriptors type: crash versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue29989> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29989] subprocess.Popen does not handle file-like objects without file descriptors
Raphael Gaschignard added the comment: the subprocess module has code to handle file objects that don't use file descriptors. It's not that file descriptors are necessary for the parameter, but that the way POpen is trying to detect "no file descriptor support" is through "fileno returns -1" rather than "fileno raises OSError" -- ___ Python tracker <http://bugs.python.org/issue29989> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29989] subprocess.Popen does not handle file-like objects without file descriptors
Raphael Gaschignard added the comment: I'm sorry for the confusion here, it turns out I was misinterpreting the results of my program and my workaround was not working. Like others have said, the subprocess code seems to rely on the existence of file descriptors I would be pretty partial to the idea of having the subprocess's internal code catch OSError and raise a clearer error message like "subprocess can only operate on files with file descriptor support". Having "complete" file object support would seem like a major win, but looking at the internals/OS support it seems like a hard thing to set up. -- ___ Python tracker <http://bugs.python.org/issue29989> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29989] subprocess.Popen does not handle file-like objects without file descriptors
Raphael Gaschignard added the comment: that error is what is raised by StringIO (subclassing OSError), other file-like objects could just be raising OSError (according to the file object spec described in the documentation for the io module). Fixing documentation would already be helpful though. I will close this issue -- stage: test needed -> resolved status: open -> closed ___ Python tracker <http://bugs.python.org/issue29989> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14610] configure script hangs on pthread verification and PTHREAD_SCOPE_SYSTEM verification on Ubuntu
New submission from Raphael Cruzeiro : While installing Python 2.7.3 on my Ubuntu server the configure script hanged on the verification for pthread, I then proceded to alter the script to aways return true for pthread and it hanged again checking for PTHREAD_SCOPE_SYSTEM, which I also bypassed by altering the script and only then was I able to successfully install Python 2.7.3 -- components: Installation messages: 158597 nosy: Raphael.Cruzeiro priority: normal severity: normal status: open title: configure script hangs on pthread verification and PTHREAD_SCOPE_SYSTEM verification on Ubuntu type: crash versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue14610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14610] configure script hangs on pthread verification and PTHREAD_SCOPE_SYSTEM verification on Ubuntu
Raphael Cruzeiro added the comment: Here is the output of sh -x ./configure -- Added file: http://bugs.python.org/file25321/output_sh ___ Python tracker <http://bugs.python.org/issue14610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14610] configure script hangs on pthread verification and PTHREAD_SCOPE_SYSTEM verification on Ubuntu
Raphael Cruzeiro added the comment: Posting the strac output -- Added file: http://bugs.python.org/file25322/strace.output.txt ___ Python tracker <http://bugs.python.org/issue14610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14610] configure script hangs on pthread verification and PTHREAD_SCOPE_SYSTEM verification on Ubuntu
Raphael Cruzeiro added the comment: Yes, this code is hanging in my system. I'm posting the strace output. If there's any other information that may be helpful I'll happily provide it. -- Added file: http://bugs.python.org/file25376/pthread_strace.txt ___ Python tracker <http://bugs.python.org/issue14610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7260] SyntaxError with a not-existing offset for unicode code
New submission from Noam Raphael :
Hello,
This is from the current svn:
> ./python
Python 3.2a0 (py3k:76104, Nov 4 2009, 08:49:44)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> try:
... eval("u'שלום'")
... except SyntaxError as e:
... e
...
SyntaxError('invalid syntax', ('', 1, 11, "u'שלום'"))
As you can see, the offset (11) refers to a non-existing character, as
the code contains only 7 characters.
Thanks,
Noam
--
components: Interpreter Core
messages: 94879
nosy: noam
severity: normal
status: open
title: SyntaxError with a not-existing offset for unicode code
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue7260>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Noam Raphael added the comment: I'm sorry, but it seems to me that the conclusion of the discussion in 2008 is that the algorithm should simply use the system's binary-to-decimal routine, and if the result is like 123.456, round it to 15 digits after the 0, check if the result evaluates to the original value, and if so, return the rounded result. This would satisfy most people, and has no need for complex rounding algorithms. Am I mistaken? If I implement this, will anybody be interested? Noam ___ Python tracker <http://bugs.python.org/issue1580> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Noam Raphael added the comment: Do you mean msg58966? I'm sorry, I still don't understand what's the problem with returning f_15(x) if eval(f_15(x)) == x and otherwise returning f_17(x). You said (msg69232) that you don't care if float(repr(x)) == x isn't cross-platform. Obviously, the simple method will preserve eval(repr(x)) == x, no matter what rounding bugs are present on the platform. ___ Python tracker <http://bugs.python.org/issue1580> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8048] doctest assumes sys.displayhook hasn't been touched
Noam Yorav-Raphael added the comment: Ok, here's a patch (against current svn of Python 2) with a test case. I had to fix three tests which combined pdb and doctest, since now, when run under doctest, pdb steps into the displayhook because it's a Python function and not a built-in function. The fix is just to return from the displayhook. If you wish, I can prepare a patch for Python 3. -- Added file: http://bugs.python.org/file16436/diff ___ Python tracker <http://bugs.python.org/issue8048> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8048] doctest assumes sys.displayhook hasn't been touched
Noam Yorav-Raphael added the comment: Here is a better and much shorter patch: I use sys.__displayhook__ instead of implementing it in Python, which has the nice side effect of not changing pdb behaviour. -- Added file: http://bugs.python.org/file16581/patch ___ Python tracker <http://bugs.python.org/issue8048> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8213] Python 3 ignored PYTHONUNBUFFERED and -u
New submission from Noam Yorav-Raphael :
Hello,
Python 3.1 ignored the PYTHONUNBUFFERED environment variable and the '-u'
switch (which do the same thing): stdout remains buffered even when the flag is
raised.
To reproduce, run:
> python3 -u -c 'import time, sys; sys.stdout.write("a"); time.sleep(1);
> sys.stdout.write("\n")'
You can see that it first waits a second and then 'a' is printed.
I'm using Ubuntu 9.10. Tested this on both the 3.1.1 installed and svn checkout
(revision 79345).
This follows a bug report: https://bugs.launchpad.net/dreampie/+bug/545012
which was reported on win32, so the problem is there too.
--
components: IO
messages: 101584
nosy: noam
severity: normal
status: open
title: Python 3 ignored PYTHONUNBUFFERED and -u
type: behavior
versions: Python 3.1
___
Python tracker
<http://bugs.python.org/issue8213>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8213] Python 3 ignored PYTHONUNBUFFERED and -u
Noam Yorav-Raphael added the comment: I typed "man python3" on ubuntu 9.10 and nothing was explained about that - I now checked and found out that it displayed the python2 man page. I don't know where to find the Python 3 man page. I don't quite see the point in having the streams buffered in one level and unbuffered in another, but I guess there's a reason. Anyway, how can I make those streams entirely unbuffered? This is for an interactive shell called DreamPie (dreampie.sourceforge.net), and I want to resemble the behavior of the regular shell as close as possible, and it's completely unbuffered. -- ___ Python tracker <http://bugs.python.org/issue8213> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8213] Python 3 ignored PYTHONUNBUFFERED and -u
Noam Yorav-Raphael added the comment: I can call flush() after the user code was executed, but a code like this: >>> for i in range(10): ... print(i, end=' ') ... time.sleep(1) will show the numbers only after 10 seconds, while I would like a number printed every second. I now see that that's what the regular shell does, so it's probably not a very big deal. -- ___ Python tracker <http://bugs.python.org/issue8213> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26092] doctest should allow custom sys.displayhook
Noam Yorav-Raphael added the comment:
Hi,
I think that using mock.patch to fix the problem is fine. I personally
haven't encountered this problem in the past years, so whatever you decide
is fine by me.
Thanks!
Noam
On Mon, Apr 26, 2021 at 10:08 AM Sergey B Kirpichev
wrote:
>
> Sergey B Kirpichev added the comment:
>
> Tim, lets decide on this simple issue.
>
> To me, https://bugs.python.org/issue8048 was obviously a bad thing.
> While it "fixes" one application, which customize sys.displayhook in a
> strange way - it break testing almost everyone, which do sys.displayhook
> customization. See e.g.
> https://github.com/sympy/sympy/blob/master/conftest.py or
> https://github.com/diofant/diofant/blob/master/conftest.py. BTW, SymPy
> is far more popular library than dreampie, which is py2-only and looks
> unmaintained.
>
> Last, but not least - introduced doctest's behaviour wasn't documented.
> It break things in a surprising way and do this silently... There is a
> documentation issue if you decide to keep this "feature".
>
> Noam, what do you think about fixing your problem with mock.patch?
>
> >>> import sys
> >>> from unittest.mock import patch
> >>> with patch('sys.displayhook', sys.__displayhook__):
> ... doctest.testmod()
>
> Tentative patch attached.
>
> --
> keywords: +patch
> Added file: https://bugs.python.org/file49985/doctest-displayhook.diff
>
> ___
> Python tracker
> <https://bugs.python.org/issue26092>
> ___
>
--
___
Python tracker
<https://bugs.python.org/issue26092>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26092] doctest should allow custom sys.displayhook
Noam Yorav-Raphael added the comment: Yes, sorry, I didn't remember the history exactly. I don't have a strong opinion. I'm okay with reverting the behavior to use sys.displayhook. Thanks, Noam -- ___ Python tracker <https://bugs.python.org/issue26092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14527] How to link with a non-system libffi?
Raphael Krut-Landau added the comment: To install Python 3.9 locally, with ctypes, this worked for me. # I created a temp directory cd ~ mkdir tmp cd tmp # I downloaded and installed the latest libffi source from Github wget "https://github.com/libffi/libffi/releases/download/v3.3/libffi-3.3.tar.gz"; tar xvf libffi-3.3.tar.gz cd libffi-3.3 ./configure --prefix=$HOME && make && make install # I now had some libffi files in ~/lib/pkgconfig and ~/lib64. # I added these to LD_LIBRARY_PATH, along with ~/lib. export LD_LIBRARY_PATH="$HOME/lib/pkgconfig:$HOME/lib:$HOME/lib64:$LD_LIBRARY_PATH" # I downloaded and installed the latest Python from python.org cd ~/tmp wget "https://www.python.org/ftp/python/3.9.0/Python-3.9.0.tgz"; cd ~/tmp/Python-3.9.0 ./configure --prefix=$HOME --with-system-ffi LDFLAGS="-L $HOME/lib64/" CPPFLAGS="-I $HOME/tmp/libffi-3.3/include/" make make test make install # I was then able to run an installer that had shown me the error, "No module named '_ctypes' pip3 install mycli I hope this can be useful to you. Raffi -- nosy: +raphael.kl versions: +Python 3.9 -Python 3.8 ___ Python tracker <https://bugs.python.org/issue14527> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26092] doctest should allow custom sys.displayhook
Noam Yorav-Raphael added the comment: Tim, thanks for letting me know. I certainly don't mind if you close this bug, since it undoes my old (and still relevant) fix. -- nosy: +noamraph ___ Python tracker <https://bugs.python.org/issue26092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35330] When using mock to wrap an existing object, side_effect requires return_value
New submission from Noam Yorav-Raphael :
When using mock to wrap an existing object, and using side_effect to set a
function to wrap a method, I would expect the wrapper function to be called
instead of the wrapped function, and its return value to be returned. Instead,
both the wrapper function and the wrapped functions are being called, and the
return value of the wrapped function is returned.
If, in addition to side_effect, return_value is set, the return_value is
ignored, but my expected behavior actually happens: only the wrapper function
is called, and its return value is returned.
Python 3.7.0 (default, Aug 22 2018, 20:50:05)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from unittest import mock
>>> class MyClass(object):
... def func(self):
... print('func called')
... return 1
...
>>> c = MyClass()
>>> m = mock.Mock(wraps=c)
>>> def func2():
... print('func2 called')
... return 2
...
>>> m.func.side_effect = func2
>>> m.func()
func2 called
func called
1
>>> m.func.return_value = 3
>>> m.func()
func2 called
2
--
components: Library (Lib)
messages: 330540
nosy: noamraph
priority: normal
severity: normal
status: open
title: When using mock to wrap an existing object, side_effect requires
return_value
type: behavior
___
Python tracker
<https://bugs.python.org/issue35330>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26199] fix broken link to hamcrest.library.integration.match_equality in unittest.mock "getting started" documentation
New submission from Raphael Das Gupta: On * https://docs.python.org/3.3/library/unittest.mock-examples.html#more-complex-argument-matching * https://docs.python.org/3.4/library/unittest.mock-examples.html#more-complex-argument-matching * https://docs.python.org/3.5/library/unittest.mock-examples.html#more-complex-argument-matching * https://docs.python.org/3.6/library/unittest.mock-examples.html#more-complex-argument-matching the link to hamcrest.library.integration.match_equality documentation at the very end of the page is broken. (Earlier versions didn't have this documentation page.) -- assignee: docs@python components: Documentation hgrepos: 332 messages: 258906 nosy: das-g, docs@python priority: normal severity: normal status: open title: fix broken link to hamcrest.library.integration.match_equality in unittest.mock "getting started" documentation versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue26199> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26199] fix broken link to hamcrest.library.integration.match_equality in unittest.mock "getting started" documentation
Changes by Raphael Das Gupta : -- keywords: +patch Added file: http://bugs.python.org/file41709/0d413f60cc23.diff ___ Python tracker <http://bugs.python.org/issue26199> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26199] fix broken link to hamcrest.library.integration.match_equality in unittest.mock "getting started" documentation
Raphael Das Gupta added the comment: 0d413f60cc23.diff generated with the 'Create Patch' button of this bug tracker is crap. (I guess it's a diff of upstream's tip to my repo's tip, thus reverting all changes of upstream that this daggy fix isn't based on.) Use fix-broken-link-to-pyhamcrest-match_equality.diff instead. (Created with hg export.) -- Added file: http://bugs.python.org/file41711/fix-broken-link-to-pyhamcrest-match_equality.diff ___ Python tracker <http://bugs.python.org/issue26199> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26199] fix broken link to hamcrest.library.integration.match_equality in unittest.mock "getting started" documentation
Raphael Das Gupta added the comment: You're welcome. Thanks for applying the patch. Shouldn't it be applied to other affected versions (3.3 and 3.4), too, though? -- ___ Python tracker <http://bugs.python.org/issue26199> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
