Noam Cohen added the comment:
that's why pre-insert conversion was suggested.
path-like objects could still be added to sys.path, while converting to str
upon insert, preserving sys.path's bytes and strings only policy.
--
___
Pyth
Noam Cohen added the comment:
So I've got in mind a PyListObject subclass with calls to PyOS_FSPath before
insert, append, extend and __getitem__.
But I feel like this is an overkill; also, extend function might be trickier to
implement.
Do any of you have better
Noam Cohen added the comment:
You've got a point.
But in my opinion path-like object usage should be intuitive and users should
not worry about converting it into string in some of the places.
What do you feel about sub-classing list for sys.path and converting path-like
objects
Change by Noam Cohen :
--
nosy: +ncohen
nosy_count: 8.0 -> 9.0
pull_requests: +30196
pull_request: https://github.com/python/cpython/pull/32118
___
Python tracker
<https://bugs.python.org/issu
Noam added the comment:
Hi Irit,
Sorry, I'm still not following,
The other issue you stated, states that PR is ready(06-2019), and this was in
2019, is this going to be fixed? or declined (and both should be closed)?
What is the current updated s
Noam added the comment:
Is this still alive? If decided to decline PR why is this still open?
--
nosy: +noamda
___
Python tracker
<https://bugs.python.org/issue29
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
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 Sturmwind added the comment:
I believe this is working as intended, but is potentially surprising behavior.
If so, perhaps a note could be added to the xml.dom documentation mentioning
that this needs to be accounted for.
Per https://stackoverflow.com/a/317494 a correct way to read the
Noam Sturmwind added the comment:
Note that the parser handles it correctly if the buffer boundary lies in the
middle of a tag name; only if it lies in the middle of text data does it result
in this behavior.
--
___
Python tracker
<ht
New submission from Noam Sturmwind :
Python 3.7.4
When parsing a file using xml.dom.pulldom.parse(), if the parser is in the
middle of text data when default_bufsize is reached it will split the text into
multiple DOM Text nodes.
This breaks code expecting that reads the text data using
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 Noam Eliahu :
ConfigParser writes data to the config file using hard-coded newline: '\n'.
This newline is not suitable for Windows. Therefore, the config file isn't
readable in Notepad.exe.
os.linesep should be used instead.
--
components: None
m
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:
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
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:
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
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
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
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:
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 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 <[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 <[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 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 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:
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:
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:
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:
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, 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:
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:
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:
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 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:
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:
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:
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:
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:
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
41 matches
Mail list logo
