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
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
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/issu
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
Raphael Mankin added the comment:
'Simple' is the problem. I will come back to you on this.
--
___
Python tracker
<http://bugs.python.org/issue9874>
___
___
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 th
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
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 you
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
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
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.
--
ve
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
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
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.)
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
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
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
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, sh
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 al
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
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):
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
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
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 t
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:
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
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/issu
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
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/issue41
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 tracke
Changes by Raphael Michel :
--
pull_requests: +3239
___
Python tracker
<http://bugs.python.org/issue31270>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 implementati
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('
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
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,
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'.
--
assi
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 withou
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
throug
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 parti
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
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
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/issue14
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/issue14
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/pth
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:
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 evalua
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-platfo
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-i
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
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; s
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
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 ever
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:
>
&g
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
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/libff
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/is
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
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
Changes by Raphael Das Gupta :
--
keywords: +patch
Added file: http://bugs.python.org/file41709/0d413f60cc23.diff
___
Python tracker
<http://bugs.python.org/issue26
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
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.o
61 matches
Mail list logo
