Emanuel Barry added the comment:
The same is true of the decimal and datetime modules. Names starting with an
underscore are an implementation detail, and you shouldn't rely on these in
production code.
--
nosy: +ebarry
___
Python tracker
Emanuel Barry added the comment:
The Python implementation will stay for two main reasons, one to provide a
working implementation for all those who wish to use a modified version (you,
for example, if you want to use a version that lets you alter order), and two
for alternate implementations
Emanuel Barry added the comment:
What about the `py' launcher? It will always launch the latest installed
version.
--
nosy: +ebarry
___
Python tracker
<http://bugs.python.org/is
Emanuel Barry added the comment:
Oh, I didn't know the py launcher preferred 2.7 - I always work with 3.x; my
bad.
--
___
Python tracker
<http://bugs.python.org/is
Emanuel Barry added the comment:
I don't know why you believe docstrings are programmatically linked to the
library reference...
Here is the file that is used to make the online documentation:
https://hg.python.org/cpython/file/tip/Doc/library/statistics.rst
--
nosy: +e
Emanuel Barry added the comment:
It probably shouldn't be assigned to docs@python, but it's still a typo in the
source code, so it should probably be under Library anyway.
LGTM
--
___
Python tracker
<http://bugs.python.o
Emanuel Barry added the comment:
> In Doc/library/smtplib.rst "a" is replaced to "an" before a word starting
> with consonant: SMTP. Is it correct?
One of the peculiriarities of the English language is that, in front of
acronyms, you have two different ways to decid
Changes by Emanuel Barry :
--
nosy: +ebarry
___
Python tracker
<http://bugs.python.org/issue21243>
___
___
Python-bugs-list mailing list
Unsubscribe:
Emanuel Barry added the comment:
`sum` has an optional `start` parameter, which defaults to 0, and is used as
the first item to add. Since timedeltas and ints are not interoperable, that
means you have to explicitly tell sum what to use.
The following code works:
>>> e=[datetime.ti
Emanuel Barry added the comment:
I think f-strings should be valid as docstrings. I don't know the exact
details, but I think it would be harder to prevent rather than allow them. It
would be exactly the same as doing func.__doc__ = func.__doc__.format(foo=foo,
bar=bar)
It probably wou
Emanuel Barry added the comment:
I was under the impression that they would work without any additional work (as
they'd have access to the outer scope). Of course, trying to access a local
variable would be an error as it's not yet defined.
My point is more that we shouldn't
Emanuel Barry added the comment:
He probably mistook this for #25179
--
nosy: +ebarry
___
Python tracker
<http://bugs.python.org/issue25579>
___
___
Python-bug
Emanuel Barry added the comment:
Well, then my bad. Pretend I didn't say anything :)
--
___
Python tracker
<http://bugs.python.org/issue25179>
___
___
Pytho
Emanuel Barry added the comment:
I would personally suggest a more permanent and accessible way, in the way the
decimal module handles it. I'd add a '_pycollections' module holding the pure
Python implementations of OrderedDict and _count_elements, then have the
collections
New submission from Emanuel Barry:
The docstring for typing.Any specifically says "- Any object is an instance of
Any."; in practice however it's not actually the case, as isinstance(x, Any)
raises a TypeError.
AnyMeta makes this behaviour seem intentional, however the official
Emanuel Barry added the comment:
Your list `l` actually holds only one list, except three times. When you change
it, it's reflected in all the lists. It's the equivalent of the following:
>>> x=['', '']
>>> l=[x, x, x]
Makes a bit more sens
Emanuel Barry added the comment:
Another way to fix this would be the following:
>>> l=[[''] * 2 for _ in range(3)]
>>> l
[['', ''], ['', ''], ['', '']]
>>> l[0][1] = "A"
>>> l
[
Changes by Emanuel Barry :
--
resolution: -> not a bug
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue25656>
___
___
Python-bugs-
Emanuel Barry added the comment:
I am unable to reproduce the issue on Windows 7 with 3.5.0; I have tried
opening a small (non-empty) text. Here's the result:
>>> import xml.etree.ElementTree as ET
>>> import gc
>>> ET.iterparse("E:/New.txt")
>
Emanuel Barry added the comment:
Oh, my bad. Ignore my last message, behaviour is identical then. Thanks for
clearing that up.
--
___
Python tracker
<http://bugs.python.org/issue25
Emanuel Barry added the comment:
I'm with Serhiy, the line number is inane. Could you put the exact contents of
your /usr/lib/python3.5/tempfile.py file somewhere for us to see? Output of
sys.version would be nice, too.
--
nosy: +ebarry
___
P
Emanuel Barry added the comment:
Your file has a lot of shenanigans that are triggered if 'shutil' fails to be
imported, adding an extra 139 lines at the top of the file, which is exactly
how offset your traceback is compared to our lines. The rest of the file is
virtually ident
Emanuel Barry added the comment:
This is due to the fact that Python 3 added the ability to define only __eq__
and get a free __ne__ defined. If my memory serves me right,
functools.total_ordering was added in 3.2 and then backported to 2.x - where
the relationship with __eq__ and __ne__ is
Emanuel Barry added the comment:
Oops, that was *completely* the wrong issue. I apologize for the noise.
--
___
Python tracker
<http://bugs.python.org/issue25
Emanuel Barry added the comment:
This is due to the fact that Python 3 added the ability to define only __eq__
and get a free __ne__ defined. If my memory serves me right,
functools.total_ordering was added in 3.2 and then backported to 2.x - where
the relationship with __eq__ and __ne__ is
Changes by Emanuel Barry :
--
assignee: docs@python ->
components: -Documentation
nosy: -docs@python
___
Python tracker
<http://bugs.python.org/issu
Emanuel Barry added the comment:
Pointed out a refleak and a small nit.
--
nosy: +ebarry
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issu
Emanuel Barry added the comment:
Looking at it again, it appears you didn't have to decref it; my bad.
Both patches LGTM.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Emanuel Barry :
--
nosy: +ebarry
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue25770>
___
___
Python-bugs-list mai
Emanuel Barry added the comment:
As Stefan said, this is not a bug with Python. Enforcing strict type checking
is the responsibility of third-party tools, not the interpreter.
--
nosy: +ebarry
resolution: -> not a bug
stage: -> resolved
status: open -&g
Emanuel Barry added the comment:
While I do see the desire to get your list back for such cases (I would have
liked so, too, in some cases), it's inconsistent, as everything else operating
in-place returns None.
Plus, having it return None helps you remember that you should kee
Changes by Emanuel Barry :
--
resolution: -> not a bug
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue25815>
___
___
Python-bugs-
Emanuel Barry added the comment:
Could you provide actual code where a reference is leaked? To me, this looks
like hypothetical failure rather than something that has a chance of occurring
- feel free to prove me wrong, though :) Please also include relevant tests.
--
nosy: +ebarry
Changes by Emanuel Barry :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue25818>
___
___
Python-bugs-list
Emanuel Barry added the comment:
The reason you are experiencing this behviour is because of the way Python
works. Python needs to compile your code before it can execute it. It parses
the code, sees an invalid token ('print "Hi"'), fails to compile and throws an
error.
Changes by Emanuel Barry :
--
versions: +Python 3.3, Python 3.4, Python 3.6
___
Python tracker
<http://bugs.python.org/issue18597>
___
___
Python-bugs-list mailin
Emanuel Barry added the comment:
Do you mean like 'filter(None, lst)' does?
--
nosy: +ebarry
___
Python tracker
<http://bugs.python.org/issue25840>
___
___
Emanuel Barry added the comment:
Nobody seems to have asked this, so I'll be that guy. In which circumstances
does comparing two code objects (at function creation time, what's more) make
any sense? I mean, I'm fine with being able to compare two code objects, but I
don
Emanuel Barry added the comment:
I'm not suggesting to get rid of the rich compare ability of code objects,
which makes sense to me. What doesn't make sense to me, however, is when a
function's code object is replaced by another one because it compares equal. I
see no use cas
Emanuel Barry added the comment:
I see. Is there any to special-case those so that only closures use that? Maybe
by checking on the function object itself - the function itself would be quite
similar, as well.
@Mark - I think you've misunderstood me (others did too, so I'm going to
Emanuel Barry added the comment:
You need to do 'import collections.abc' as abc is a submodule of collections,
and is not imported from a bare 'import collections'.
--
nosy: +ebarry
___
Python tracker
<http://bug
Emanuel Barry added the comment:
Reviewed the Python code (unlike what my email said, it doesn't LGTM; I'm tired
and just forgot). I checked the C code for the obvious pitfalls (didn't spot
any), but it will require someone else better than me to look at it.
--
nosy
Emanuel Barry added the comment:
*.pyo files have been removed from the language as of 3.5; instead, the
optimization is done directly to the *.pyc files. Are you suggesting
re-introducing *.pyo files or changing this behaviour in the current model?
Also, 'if type(obj) is int' is
Changes by Emanuel Barry :
--
nosy: +ebarry
___
Python tracker
<http://bugs.python.org/issue25907>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Emanuel Barry :
--
nosy: +ebarry
___
Python tracker
<http://bugs.python.org/issue25925>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Emanuel Barry :
--
nosy: +ebarry
stage: resolved -> patch review
title: operator.subscript -> Add operator.subscript as a convenience for
creating slices
___
Python tracker
<http://bugs.python.org/i
Emanuel Barry added the comment:
Set displays appear to be the culprit here:
>>> class A:
... count = 0
... def __init__(self):
... self.cnt = self.count
... type(self).count += 1
... def __eq__(self, other):
... return type(self) is type(other)
... def __ha
Emanuel Barry added the comment:
Think you can submit a patch?
--
keywords: +easy
nosy: +ebarry
stage: -> needs patch
title: Typo -> Typo in documentation of unittest
___
Python tracker
<http://bugs.python.org/i
Emanuel Barry added the comment:
The choice of IPython to depend on a private, undocumented method means that
they are subject to such bugs. A quick Google search tells me you should
probably report the issue here: https://github.com/ipython/ipython/issues
--
nosy: +ebarry
status
Emanuel Barry added the comment:
Truncating at 200 characters is actually a common occurrence in the C code,
just barely anyone notice this, as it's not common to need more than 200
characters for most expressions.
I don't think this needs to be changed at all; the rare case should
Changes by Emanuel Barry :
--
nosy: +ebarry
___
Python tracker
<http://bugs.python.org/issue26060>
___
___
Python-bugs-list mailing list
Unsubscribe:
Emanuel Barry added the comment:
You seem to have forgotten to include a patch.
--
nosy: +ebarry
___
Python tracker
<http://bugs.python.org/issue26069>
___
___
Emanuel Barry added the comment:
This is an interesting idea, +1 from me. Do you want to submit a patch?
--
nosy: +ebarry
stage: -> needs patch
versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5
___
Python tracker
&l
Changes by Emanuel Barry :
--
components: +Tests
stage: test needed -> needs patch
___
Python tracker
<http://bugs.python.org/issue24780>
___
___
Python-
Emanuel Barry added the comment:
NumPy isn't a part of CPython. As haypo said, please submit that to their
tracker instead.
--
nosy: +ebarry
resolution: -> third party
stage: -> resolved
status: open -> closed
___
Python
New submission from Emanuel Barry:
I compiled CPython from latest trunk on GitHub (revision
a587bc1eea903dfac94a85324cc6ab39755769a8), compiled with Py_DEBUG and went to
run the test suite. Here's the (rather long) output:
E:\GitHub\cpython\PCbuild\win32>python_d -m test
== CPython
Emanuel Barry added the comment:
This fixed it, thanks!
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue26217>
___
___
Python-
Changes by Emanuel Barry :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Emanuel Barry :
--
stage: -> needs patch
versions: +Python 3.6
___
Python tracker
<http://bugs.python.org/issue26226>
___
___
Python-bugs-list mai
New submission from Emanuel Barry:
Compiled latest master and ran test suite (Py_DEBUG build). A few failures here
and there, and some tests skipped. I haven't yet looked into getting the proper
libraries to make some of the skipped tests execute, I'm trying to make the
whole test
Emanuel Barry added the comment:
Well, it has a non-ASCII character in it, so I wouldn't be surprised if this
was the issue :)
Latest master (3.6):
>>> import socket
>>> socket.gethostname()
'Émanuel-PC'
>>> socket.gethostbyaddr(socket.gethostname())
Emanuel Barry added the comment:
FWIW this patch doesn't fix the test_httpservers failure (or any other) in
#26226
--
___
Python tracker
<http://bugs.python.org/is
Emanuel Barry added the comment:
If it worked for you, I assume it's fine and I probably did something wrong on
my side. Thanks for the fix!
--
___
Python tracker
<http://bugs.python.org/is
Emanuel Barry added the comment:
Oh, sorry. The patch applies without any problem, then I re-compile everything
and run, and the same error happens. I re-compiled just now to make double sure.
--
___
Python tracker
<http://bugs.python.
Emanuel Barry added the comment:
Yes, it's not all that urgent. And Victor's latest patch doesn't work, either :(
I wonder if there's a way to (temporarily) modify the output of
``socket.gethostname()`` to be able to test suc
Emanuel Barry added the comment:
For future reference, Victor's patch does fix it, I was checking the wrong
thing when testing.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Emanuel Barry :
--
nosy: +ebarry
___
Python tracker
<http://bugs.python.org/issue26110>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Emanuel Barry :
--
nosy: +ebarry
title: Possible bug in time library -> time.strptime does not properly convert
out-of-bounds values
versions: -Python 3.2, Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issu
Emanuel Barry added the comment:
Left a comment on Rietveld. I don't have time right now to check the test, but
I suspect you tested it before submitting the patch, so it should probably be
fine.
--
nosy: +ebarry
stage: -> patch review
__
Emanuel Barry added the comment:
This is due to how floating point numbers are handled under the hood. See
http://effbot.org/pyfaq/why-are-floating-point-calculations-so-inaccurate.htm
and https://docs.python.org/3/tutorial/floatingpoint.html for some useful read
about why Python behaves like
Emanuel Barry added the comment:
This is consistent with the advertised equivalence of sum():
>>> -0.0 + -0.0 + 0
0.0
This works as you'd expect:
>>> sum([-0.0, -0.0], -0.0)
-0.0
It has a start value of 0, and I don't think we should special-case thi
Emanuel Barry added the comment:
"Not trivial" might be an understatement. You need the start value to begin
summing the items, but you may face with a non-repeatable generator with
side-effects. Sure, you could special-case some builtins, but I'm not too keen
on adding special
Changes by Emanuel Barry :
--
assignee: -> serhiy.storchaka
nosy: +ebarry, serhiy.storchaka
stage: -> needs patch
type: -> behavior
___
Python tracker
<http://bugs.python.or
Changes by Emanuel Barry :
--
nosy: +ebarry
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue26546>
___
___
Python-bugs-list mai
New submission from Emanuel Barry:
`shutil.get_terminal_size()` will sometimes propagate `AttributeError: module
has not attribute 'get_terminal_size'` to the caller. The call checks for
NameError, which makes no sense, so I guess it must be an oversight. Attached
patch fixes it.
Emanuel Barry added the comment:
I think Rietveld doesn't like me because I made it a .diff file, and not a
.patch file, but who knows.
It's a bit of a shot in the dark though, because I can't reproduce an
environment where `os.get_terminal_size()` doesn't exist. I'm
Emanuel Barry added the comment:
On posix-based OSes, `os.get_terminal_size` might not exist (
https://hg.python.org/cpython/file/default/Modules/posixmodule.c#l12462 ), so
this is needed.
New patch file with tests included.
--
Added file: http://bugs.python.org/file42522
Emanuel Barry added the comment:
Hmm, if `sys.__stdout__` was deleted (or set to `None`), this would also raise
an `AttributeError` when calling `shutil.get_terminal_size`, so I think that
even if `os.get_terminal_size` is guaranteed to be always present (which it's
not, IIUC), cat
Changes by Emanuel Barry :
Added file: http://bugs.python.org/file42523/get_term_size_with_test2.patch
___
Python tracker
<http://bugs.python.org/issue26801>
___
___
Pytho
Emanuel Barry added the comment:
To be fair, I don't think we actually need a unit test to check if
`os.get_terminal_size` exists, as we catch any `AttributeError` at all. I'd
want to keep the except clause there to properly handle `sys.__stdout__` being
`None` (or simply absen
Emanuel Barry added the comment:
Patch fixes this the proper way by defining __all__ in the string module.
--
keywords: +patch
nosy: +ebarry
Added file: http://bugs.python.org/file42536/string___all__.patch
___
Python tracker
<http://bugs.python.
Emanuel Barry added the comment:
Thanks SilentGhost, seems my brain decided not to see uppercase names :)
Attached patch adds Formatter and Template as well.
--
Added file: http://bugs.python.org/file42537/string___all___2.patch
___
Python tracker
Emanuel Barry added the comment:
I added an underscore in front of ChainMap, but I kept the __all__ definition
because I think it should be there regardless (like every module, basically).
--
Added file: http://bugs.python.org/file42540/ChainMap___all__.patch
Changes by Emanuel Barry :
Added file: http://bugs.python.org/file42541/ChainMap___all___2.patch
___
Python tracker
<http://bugs.python.org/issue26809>
___
___
Python-bug
New submission from Emanuel Barry:
I recently suggested on Python-ideas (
https://mail.python.org/pipermail/python-ideas/2016-April/039899.html ) to
shrink long tracebacks if they were all the same noise (recursive calls).
Seeing as the idea had a good reception, I went ahead and implemented
Emanuel Barry added the comment:
Yes, can't handle mutually recursive functions. I could maybe check for the
last two or three functions, but that seems like unnecessary work for something
that might not happen as often (I can see it being the case with e.g.
__getattr__ though).
If e
Emanuel Barry added the comment:
The message is mostly a placeholder, but "message" is singular so I figured it
would be obvious. But alas, if you are confused, others might be too.
Propositions for a better message are welcome :)
I'll attempt to make it track chained cal
Emanuel Barry added the comment:
Attached patch also modifies Lib/traceback.py to present identical behaviour,
and changes "Previous message" to "Previous line". I'll postpone the more
complex implementation of that, and might just not do it as it's indeed bet
Emanuel Barry added the comment:
New version with tests now, I test both the C and Python implementations.
--
assignee: -> ebarry
Added file: http://bugs.python.org/file42570/short_tracebacks_3.patch
___
Python tracker
<http://bugs.pyth
Emanuel Barry added the comment:
The documentation looks fine to me. Are you seeing any other place that I'm
missing?
https://docs.python.org/3/library/functions.html#divmod
--
nosy: +ebarry
___
Python tracker
<http://bugs.python.org/is
Emanuel Barry added the comment:
Using a simple metaclass shows that definition order is not at fault here:
>>> class PrintOrder(dict):
... def __setitem__(self, item, value):
... print(item, value)
... super().__setitem__(item, value)
...
>>> class Show(type):
...
Emanuel Barry added the comment:
Forward slashes work fine in Windows, for both the command line and PowerShell.
Windows always displays backslahes, but accepts either (as well as any
combination of both) in paths.
--
assignee: docs@python ->
nosy: +ebarry
resolution: -> not
Emanuel Barry added the comment:
I realize that I haven't given any update on this since my last patch. I
figured that trying to detect when an arbitrary number of functions call each
other in a convoluted call chain isn't a very good idea.
Not only is it way beyond my abilities, b
New submission from Emanuel Barry:
I got a random UnicodeDecodeError while trying to install a module with
distutils. Traced it back and it being my name having a non-ascii character
floating around in my environment.
I'm including two patches: subprocess_errors_simple_1.patch simply
Changes by Emanuel Barry :
Added file: http://bugs.python.org/file42881/subprocess_distutils_errors_1.patch
___
Python tracker
<http://bugs.python.org/issue27048>
___
___
Changes by Emanuel Barry :
Added file: http://bugs.python.org/file42883/subprocess_distutils_errors_2.patch
___
Python tracker
<http://bugs.python.org/issue27048>
___
___
Emanuel Barry added the comment:
The data that causes the issue is my name (Émanuel), which is present in a
couple of places in my environment. I also completely forgot about
surrogateescape, my bad. Here are two new patches with the surrogateescape
error handler instead of the replace one
Emanuel Barry added the comment:
Oops, I thought I had written that - must have accidentally deleted it. I'm on
Windows 7, my locale is fr-CA / cp1252, and the non-ascii data (my name =)
comes from my environment.
I discussed a bit with R. David Murray off-issue, and in the end it seems
Emanuel Barry added the comment:
You are right Martin, this also fixes it, and it seems much less controversial
:) Here you go.
--
Added file: http://bugs.python.org/file42885/distutils_windows_non_ascii_1.patch
___
Python tracker
<h
Emanuel Barry added the comment:
Yes, and it seems that it is waiting for a review.
http://bugs.python.org/issue25782
--
nosy: +ebarry
___
Python tracker
<http://bugs.python.org/issue27
201 - 300 of 358 matches
Mail list logo
