[issue35595] Add sys flag to always show full paths in stack traces (instead of relative paths)
Steven D'Aprano added the comment: Python 2.7 is (almost) end of life and well beyond feature-freeze, so this can only go into 3.8 or better. Since the paths logged are relative to the current working directory, perhaps you could just have your script log the working directory? -- nosy: +steven.daprano type: -> enhancement versions: -Python 2.7 ___ Python tracker <https://bugs.python.org/issue35595> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35575] Improved range syntax
Steven D'Aprano added the comment: These proposals probably should be discussed on Python-Ideas first. You should also familiarize yourself with previous proposals to enhance range, such as https://mail.python.org/pipermail/python-ideas/2018-November/054510.html and the bug report #35200 For what it is worth, Guido was generally (slightly) opposed to "constant bool parameters", functions that take a parameter which is generally given as a literal True/False flag. That's often (not always) a design smell. I agree with him, so I would be very wary about adding not one but two such constant bool parameters. Especially for such a trivial enhancement. There's nothing in the `inc_start=True, inc_stop=False` functionality which can't be more easily done by simply adding one to the appropriate range arguments: # same as inc_start=False, inc_stop=True but easier range(start+1, end+1) You say: "a mix of round parentheses and square brackets could be allowed" but I think such a proposal would run foul of the requirement that Python's grammar be no more complex than LL(1). (Someone will correct me if I'm wrong.) -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue35575> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35574] Coconut support
Steven D'Aprano added the comment: One more thing: if you intend to proceed with this, either as individual enhancements or a PEP, you should discuss them on the Python-Ideas mailing list first, to see how much or little community support the proposals have. Until then, I'm closing this as "Postponed". -- resolution: -> postponed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue35574> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35574] Coconut support
Steven D'Aprano added the comment: Do you have agreement from the maintainer(s) of Coconut that they are willing to put Coconut into the Python language and/or std library? Given that Coconut is effectively a radically different language from Python (a superset of Python) this is not a small change. While it is at least possible that we would consider individual features from Coconut, integrating the two languages is unlikely. That would basically turn Python into Coconut and make Python obsolete. In any case, as a radical change, possibly as big as the move from Python 2 to 3, this will absolutely need a PEP. https://www.python.org/dev/peps/ You say: "Coconut allows making code *so* much more readable." but that's your opinion, I'm sure that there are many people who don't like or appreciate the sort of functional idioms which Coconut specializes in. But having said that, I personally do like *some* of the Coconut syntax. I think a more productive approach will be to propose *individual* enhancements, allowing each enhancement to be considered on its own merits, rather than suggesting the two languages be integrated. That sort of "everything or nothing" approach is almost certainly going to get the response "OK, nothing". As for the IDE support, that's not our problem. We're not responsible for convincing IDEs to provide better support for every experimental third-party language. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue35574> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35576] function splitextTest does not return expected value
Steven D'Aprano added the comment: Please provide a proper reproducible bug report. Don't make us GUESS what function you are referring to. I don't know any "splitextTest" function that you describe in the bug report title. Do you mean os.path.splitext? Then you should say so. If not, then what function are you referring to? What results do you expect, why do you expect them, and what results do you get? Why should we care what test results some Java library returns? Maybe they've got it wrong, or maybe their function just works differently from ours. Unless this function is documented as being exactly compatible with the Java code you link to, I don't think it is very important what guava does. Perhaps you should raise a bug report at Guava and tell them that according to the Python language, their function is wrong. The os.path.splitext function is documented as returning the file extension as either the empty string "" or beginning with a single period, and leading dots are not part of the extension. So the examples you show are correct, if you are talking about os.path.splitext. If you are talking about something else, please explain what. https://docs.python.org/3/library/os.path.html#os.path.splitext -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue35576> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35573] is_HDN is returns false positive and false negative value for two test cases respectively
Steven D'Aprano added the comment: What is the module "cookiejar" you are importing? Is that a third-party module? It doesn't seem to be in the standard library. There is a module `http.cookiejar` but it doesn't seem to have an `is_HDN` function. If this is a third-party library, please close this and report it to the maintainers of that library. Can you please explain *why* these are "false positive" and "false negative", and which is which? In particular, do you know for a fact that the test cases you reference actually pass, and are correct if they pass? I'm not an expert, but I don't think domain names can end with a dot, and the "woo.com." test case is the *only* one which ends with a dot, so I suspect it may be a typo, and the test case doesn't actually pass. (Or if it does pass, perhaps it shouldn't.) -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue35573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35549] Add partial_match: bool = False argument to unicodedata.lookup
Steven D'Aprano added the comment:
Here's my implementation:
from unicodedata import name
from unicodedata import lookup as _lookup
from fnmatch import translate
from re import compile, I
_NAMES = None
def getnames():
global _NAMES
if _NAMES is None:
_NAMES = []
for i in range(0x11):
s = name(chr(i), '')
if s:
_NAMES.append(s)
return _NAMES
def lookup(name_or_glob):
if any(c in name_or_glob for c in '*?['):
match = compile(translate(name_or_glob), flags=I).match
return [name for name in getnames() if match(name)]
else:
return _lookup(name_or_glob)
The major limitation of my implementation is that it doesn't match name aliases
or sequences.
http://www.unicode.org/Public/11.0.0/ucd/NameAliases.txt
http://www.unicode.org/Public/11.0.0/ucd/NamedSequences.txt
For example:
lookup('TAMIL SYLLABLE TAA?') # NamedSequence
ought to return ['தா'] but doesn't.
Parts of the Unicode documentation uses the convention that canonical names are
in UPPERCASE, aliases are lowercase, and sequences are in Mixed Case. and I
think that we should follow that convention:
http://www.unicode.org/charts/aboutcharindex.html
That makes it easy to see what is the canonical name and what isn't.
--
___
Python tracker
<https://bugs.python.org/issue35549>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35549] Add partial_match: bool = False argument to unicodedata.lookup
Steven D'Aprano added the comment:
I love the idea, but dislike the proposed interface.
As a general rule of thumb, Guido dislikes "constant bool parameters", where
you pass a literal True or False to a parameter to a function to change its
behaviour. Obviously this is not a hard rule, there are functions in the stdlib
that do this, but like Guido I think we should avoid them in general.
Instead, I think we should allow the name to include globbing symbols * ? etc.
(I think full blown re syntax is overkill.) I have an implementation which I
use:
lookup(name) -> single character # the current behaviour
lookup(name_with_glob_symbols) -> list of characters
For example lookup('latin * Z') returns:
['LATIN CAPITAL LETTER Z', 'LATIN SMALL LETTER Z', 'LATIN CAPITAL LETTER D WITH
SMALL LETTER Z', 'LATIN LETTER SMALL CAPITAL Z', 'LATIN CAPITAL LETTER
VISIGOTHIC Z', 'LATIN SMALL LETTER VISIGOTHIC Z']
A straight substring match takes at worst twelve extra characters:
lookup('*' + name + '*')
and only two if the name is a literal:
lookup('*spam*')
This is less than `partial_match=True` (18 characters) and more flexible and
powerful. There's no ambiguity between the two styles of call because the
globbing symbols * ? and [] are never legal in Unicode names. See section 4.8 of
http://www.unicode.org/versions/Unicode11.0.0/ch04.pdf
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issue35549>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35544] unicode.encode docstring says return value can be unicode
Steven D'Aprano added the comment: > I'll keep on finding "-> string or unicode" misleading. How is it misleading when its true? -- ___ Python tracker <https://bugs.python.org/issue35544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35544] unicode.encode docstring says return value can be unicode
Steven D'Aprano added the comment:
Encoding and decoding, in the most general sense, can include unicode ->
unicode and bytestring -> bytestring.
I can't see any standard unicode->unicode encodings in Python 2.7
https://docs.python.org/2/library/codecs.html
but we can create one:
py> import codecs
py> class NullCodec(codecs.Codec): # "do nothing" codec
... def encode(self, input, errors='strict'):
... return (input, len(input))
... def decode(self, input, errors='strict'):
... return (input, len(input))
...
py> def getregentry(name):
... return codecs.CodecInfo(
... name='null',
... encode=NullCodec().encode,
... decode=NullCodec().decode,
... incrementalencoder=None,
... incrementaldecoder=None,
... streamwriter=None,
... streamreader=None,
... )
...
py> codecs.register(getregentry)
py> u'unicode text'.encode('null')
u'unicode text'
so the documentation is correct, and the Stackoverflow answer is not.
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issue35544>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35530] Counter-intuitive logging API
Steven D'Aprano added the comment: On Wed, Dec 19, 2018 at 10:37:22AM +, Mark Dickinson wrote: > > Mark Dickinson added the comment: > > The call to `logging.error` is *not* irrelevant here. It's causing an > implicit, and surprising (albeit documented), call to > `logging.basicConfig`. Ah, thanks. And of course the documentation you refer to is right there in the paragraph above the one I linked to earlier, and I completely missed it. Ouch. -- ___ Python tracker <https://bugs.python.org/issue35530> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35530] Counter-intuitive logging API
Steven D'Aprano added the comment: > That's true. Maybe and warning or Exception can be raise? Why would we raise a warning or exception for expected behaviour? logging.error() and some_instance.error() don't necessarily produce the same output. What would the exception say? FatalError: no error occurred *wink* > and 3.8? If you have 3.8 installed, feel free to test the code yourself and report what happens. -- ___ Python tracker <https://bugs.python.org/issue35530> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35530] Counter-intuitive logging API
Steven D'Aprano added the comment: The call to logging.error() is irrelevant, since there's no expectation that the module-level function will necessarily output the same as a method of a specific instance logger.error(). I agree that is it quite curious that the first call to logger.error outputs something different from the second. The documentation says: The default format set by basicConfig() for messages is: severity:logger name:message ( Paragraph just above this: https://docs.python.org/3.5/howto/logging.html#logging-flow ) but you don't call basicConfig. I'm not sure that it is mandatory though. It looks like a bug to *me*, but I'm not a logging expert. I'm seeing the same behaviour in 3.5 and 3.7, but in 2.7.1 the first call to logger.error prints an error message: No handlers could be found for logger "main" -- nosy: +steven.daprano, vinay.sajip ___ Python tracker <https://bugs.python.org/issue35530> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35522] os.stat().st_ctime and time.time() mismatch
Steven D'Aprano added the comment: In the future, please describe your problem here, on the bug tracker, not just by linking to Stackoverflow. You asked: "Why is the file creation time [less than] the time measured before it is created?" (You actually say "greater than" on Stackoverflow, but the example given shows you mean less than). ctime does not mean "creation time" on Linux systems. https://www.unix.com/tips-and-tutorials/20526-mtime-ctime-atime.html https://stackoverflow.com/questions/27549217/ctime-atime-and-mtime-how-to-interpret-them As for the ctime being earlier than the pre-recorded timestamp, I'm confident that will have something to do with the resolution of ctime versus time.time. The time.time() function may have a resolution of as little as 1 second on some systems: https://docs.python.org/3/library/time.html#time.time so the fraction after the decimal point could be more or less random. Alternatively, the resolution of ctime may not be the same as time.time(). See the documentation: https://docs.python.org/3/library/os.html#os.stat_result I don't think this is a bug, I think this is an unavoidable consequence of the interaction between two different time measurements with slightly different resolutions. If you believe differently, can you explain why you think it is a bug? Since time.time() simply returns the time according to the OS, and os.stat gives the ctime as recorded by the file system, I don't think there is anything Python can do about this even if it is a bug. It would be a bug in the OS or file system. If you disagree, please explain why. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue35522> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35496] left-to-right violation in match order
Steven D'Aprano added the comment:
> See attached script, which is self-explanatory.
I'm glad one of us thinks so, because I find it clear as mud.
I spent *way* longer on this than I should have, but I simplified your sample
code to the best of my ability. (See attached.) As far as I can tell, your code
and mine does roughly the same thing, but please check that you agree.
I agree that with the IPV6 portion of the regex removed, it matches on
"208.123.4.22", but with the IPV6 portion included, it matches on
":::208.123.4.22". But I'm not sure that's a bug. I think it is working as
designed. For example:
py> import re
py> text = 'green pepper'
py> re.search('pepper|green pepper', text).group(0)
'green pepper'
seems to be analogous to your example, but simpler. Do you agree? If not, it
would also help a lot if you could find a simpler regex that demonstrates the
issue. See http://www.sscce.org/
In your case, I believe that the rightmost alternative matches from position 1
of the text, while the leftmost alternative doesn't match until position 8. So
starting from position 0, the IPV6 check matches first, and so wins.
It is possible you were expecting that the IPV4 check would be tested against
position 0, then position 1, then position 2, then ... and so on until the end
of the string, and only then the IPV6 check tested against position 0, then 1
etc.
--
nosy: +steven.daprano
Added file: https://bugs.python.org/file48000/logcheck3.py
___
Python tracker
<https://bugs.python.org/issue35496>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35449] documenting objects
Steven D'Aprano added the comment: I asked: > > Are you suggesting we need new syntax to automatically assign docstrings > > to instances? Stefan replied: > No, I'm not suggesting that. And then immediately went on to suggest new syntax for automatically binding a string to objects as docstrings. I am amused :-) Whether you want to call it "new semantics for existing syntax" or "new syntax" is a matter of terminology. The point is, you are suggesting something that requires dedicated support from the interpreter, as opposed to merely writing some Python code. > I'm suggesting that within the current > syntax, some additional semantic rules might be required to bind > comments (or strings) to objects as "docstrings". To my mind, it makes sense to have dedicated docstring syntax for classes, modules and functions: I expect that they will make up in excess of 95% of use-cases for docstrings. In this case, special cases *are* special enough to change the rules. But for the rare(?) cases of wanting to add docstrings to arbitrary instances, I don't think it is justified to have dedicated syntax to do it. It's easy enough and more than flexible enough to just do an instance attribute assignment: instance.__doc__ = """This is the instance docstring.""" I strongly oppose any suggestion that *comments* be treated as code: > foo = 123 > # This is foo's docstring Deleting comments shouldn't make have any runtime effect on the code, but in this case it would. (I'm willing to make an exception for the optional encoding cookie at the beginning of modules, as a rather special case.) So I think there are three related but separate issues here: 1. help(obj) and possibly PyDoc in general ought to support per-instance docstrings. I think that is uncontroversial and we just need somebody to do the work to make it happen. 2. Add special syntactic sugar to automatically associate a string with arbitrary instances as a docstring. I think that's overkill and unnecessary, but I'd be willing to be convinced otherwise. 3. Your examples suggest that even built-in immutable objects like ints should be able to take docstrings. I don't think that idea is going to fly, but I'm also not sure how serious you are about that. It runs into the problem that small ints and certain strings are cached, so your docstring could clobber my docstring. It is also going to require the addition of an extra attribute slot to every int, str, etc for the docstring, even if 99.999% of them never use it. > It would be great to establish a convention for this, so in the future > tools don't have to invent their own (non-portable) convention. ``instance.__doc__ = "docstring"`` seems pretty portable to me :-) -- ___ Python tracker <https://bugs.python.org/issue35449> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35449] documenting objects
Steven D'Aprano added the comment: > Is there any discussion concerning what syntax might be used for > docstrings associated with objects ? I don't know about PyDoc in general, but I would expect help(obj) to just use obj.__doc__ which will return the instance docstring if it exists, and if not, the type docstring (if it exists). No new syntax is required, the standard ``help(obj)`` is sufficient. > (There seem to be some partial > solutions added on top of the Python parser (I think `epydoc` offered > one), but it would be nice to have a built-in solution to avoid having > to re-invent wheels. Are you suggesting we need new syntax to automatically assign docstrings to instances? I don't think we do. I expect that if you want to set a custom instance docstring, you would just say ``instance.__doc__ = "The doc string"`` after creating the instance, or ``self.__doc__ = "..."`` inside the __init__ method. -- ___ Python tracker <https://bugs.python.org/issue35449> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35449] documenting objects
Steven D'Aprano added the comment: Minor note on terminology: classes and functions are themselves objects. I think that help() (or in particular PyDoc in general) should support any instance with a __doc__ attribute. Its failure to do so is causing pain, see #12154. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue35449> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35443] Add Tail Call Optimization
Steven D'Aprano added the comment: > I see nothing wrong with adding Tail Call Optimization to Python. That's nice. Is that supposed to be an argument that convinces us? You are hardly the first person ever to suggest TCO for Python: https://duckduckgo.com/?q=tail+call+optimization+site%3Ahttps%3A%2F%2Fmail.python.org Unless you have a more convincing argument than the arguments previously made, and rejected, this ticket will be closed. Even though this has been rejected in the past, the door is not quite closed. In a couple of weeks, Guido will be replaced as BDFL, and the new governor(s) may be more receptive to this idea. But you will probably need to write a PEP. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue35443> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35105] Document that CPython accepts "invalid" identifiers
Steven D'Aprano added the comment: > Any ideas? Or I will create a PR in a week without 'CPython implementation > detail' I don't think we want to give any stability guarantees for this. Perhaps we should explicitly state that this is not guaranteed behaviour and may change in the future. I would be happy for it to be stated as an CPython implementation detail. If PyPy or any other implementation happen to duplicate it, we're not responsible for documenting that fact. Please go ahead and make a PR. -- ___ Python tracker <https://bugs.python.org/issue35105> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35431] Add a function for computing binomial coefficients to the math module
Steven D'Aprano added the comment: Brett, what was the purpose of the title change? > title: The math module should provide a function for computing > binomial coefficients -> Add a function for computing binomial > coefficients to the math module -- ___ Python tracker <https://bugs.python.org/issue35431> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35431] The math module should provide a function for computing binomial coefficients
Steven D'Aprano added the comment: On Fri, Dec 07, 2018 at 01:37:36PM +, Mark Dickinson wrote: > I'd personally prefer that floats not be accepted; Agreed. We can always add support for floats later, but its hard to remove it if it turns out to be problematic. We ought to require n, r (or n, k) to be non-negative ints with 0 <= r <= n. Extending this to negative ints or floats is probably YAGNI, but if somebody does need it, they can request an enhancement in the future. -- ___ Python tracker <https://bugs.python.org/issue35431> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35431] The math module should provide a function for computing binomial coefficients
Steven D'Aprano added the comment:
> > Mathematically, `binomial(n, k)` for `k > n` is defined as 0.
>
> It's not so clear cut. You can find different definitions out there.
> Knuth et. al., for example, in the book "Concrete Mathematics", extend
> the definition not just to negative k, but to negative n as well.
> Mathematicians aren't very good at agreeing on things. :-)
I think the key word there is *extend*. To the degree that any
mathematical definition is "obvious", the obvious definition for number
of combinations ("n choose r") is going to be 1 for r == 0 and 0 for r > n.
However, I think that it is too easy to get the order of n and r (n and
k) mixed up, and write combinations(5, 10) when you wanted to choose 5
from 10. I know I make that mistake on my calculator *all the time*, and
so do my students, even with the nPr notation. So I recommend we raise
ValueError for r > n.
--
___
Python tracker
<https://bugs.python.org/issue35431>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35431] The math module should provide a function for computing binomial coefficients
Steven D'Aprano added the comment: On Fri, Dec 07, 2018 at 12:04:44AM +, Raymond Hettinger wrote: > Also, I'm not sure what the predominant choice for variable names > should be, "n things taken r at a time" or "n things taken k at time". > > Also, it's worth considering whether the function should be called > "binomial", "choose", "combinations", or "comb". I've done a quick survey of some of the most common/popular scientific calculators: TI Nspire TI-84 Plus Casio Classpad Casio FX-82AU Plus II all call this nCr, and nPr for the permutation version. This matches the notation taught in secondary school maths classes in Australia. That's common and familiar notation for secondary school students, but personally I'm not super-keen on it. For what its worth, the colour I prefer for this bikeshed are "comb" and "perm", which are the names used by the HP 48GX calculator. Second choice would be to spell the names out in full, "combinations" and "permutations". -- ___ Python tracker <https://bugs.python.org/issue35431> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35435] Documentation of 3.3 is available
Steven D'Aprano added the comment: Documentation is available for all versions going back to Python 1.4. https://docs.python.org/release/1.4/ As it should be: I'm surely not the only person who has need to check old versions of the documentation from time to time. Not everyone is using the latest version of Python, and some times we need to write code that supports old versions. Leaving the old docs available is not merely "doesn't hurt", but is positively a GOOD thing to do. We shouldn't remove the docs from the server, and we shouldn't break existing URLs. I don't think there's much we can do about search engines: they have their secret algorithms for ranking pages, and whatever comes up is what comes up, and I doubt we can control that. I expect that the only thing we could do is put a prominent note at the top of each page "This is an unsupported version of the docs, for the latest version see blah blah blah" and link to the most recent version. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue35435> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35431] The math module should provide a function for computing binomial coefficients
Steven D'Aprano added the comment: You import reduce but never use it :-) +1 for this, I certainly miss it too. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue35431> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35407] Datetime function with selenium
Steven D'Aprano added the comment: This is for reporting bugs in the Python interpreter and standard library, not for asking for help with bugs in your own code. The code you show contains a syntax error (some of the indentation is wrong) and at least one undefined variable, "new". The traceback you got would have shown you that: py> data_date = new.date() # data_date is the date fetched from website Traceback (most recent call last): File "", line 1, in NameError: name 'new' is not defined You need to define "new" before you can use it. Since this is not a bug in Python, I'm closing this. If you disagree, please read this website: http://sscce.org/ copy and paste the full exception you get, and be prepared to explain why it is a bug in the interpreter rather than in your code. -- nosy: +steven.daprano resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue35407> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35403] support application/wasm in mimetypes and http.server
Steven D'Aprano added the comment: Python 3.7 is in feature-freeze, so any new features like this will have to be 3.8 only. -- nosy: +steven.daprano versions: -Python 3.7 ___ Python tracker <https://bugs.python.org/issue35403> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35397] Undeprecate and document urllib.parse.unwrap
New submission from Steven D'Aprano :
The urllib.parse module contains an undocumented function unwrap:
unwrap('') --> 'type://host/path'
This is useful. I've been re-inventing this function in many of my scripts,
because I didn't know it existed (not documented!) and only stumbled across it
by accident today, where I see it was deprecated in #27485 but I can't see any
reason for the deprecation.
If not for the deprecation, I would certainly use this unwrap function in
preference to rolling my own.
It seems to me that this might have been a case of an over-enthusiastic change.
#27485 talks about deprecating the various split* functions, which are
officially redundant (urlparse and urlsplit are preferred) but doesn't talk
about unwrap, which is useful and (in my opinion) should have been documented
rather than deprecated.
--
messages: 331003
nosy: cheryl.sabella, serhiy.storchaka, steven.daprano
priority: normal
severity: normal
status: open
title: Undeprecate and document urllib.parse.unwrap
type: enhancement
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue35397>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35377] urlparse doesn't validate the scheme
Steven D'Aprano added the comment:
I'm changing the name to better describe the problem, and suggest a better
solution.
The urlparse.urlsplit and .urlunsplit functions currently don't validate the
scheme argument, if given. According to the RFC:
Scheme names consist of a sequence of characters. The lower case
letters "a"--"z", digits, and the characters plus ("+"), period
("."), and hyphen ("-") are allowed. For resiliency, programs
interpreting URLs should treat upper case letters as equivalent to
lower case in scheme names (e.g., allow "HTTP" as well as "http").
https://www.ietf.org/rfc/rfc1738.txt
If the scheme is specified, I suggest it should be normalised to lowercase and
validated, something like this:
# untested
if scheme:
# scheme_chars already defined in module
badchars = set(scheme) - set(scheme_chars)
if badchars:
raise ValueError('"%c" is invalid in URL schemes' % badchars.pop())
scheme = scheme.lower()
This will help avoid errors such as passing 'http://' as the scheme.
--
keywords: -patch
stage: patch review ->
title: urlsplit scheme argument broken -> urlparse doesn't validate the scheme
versions: +Python 3.8 -Python 2.7, Python 3.7
___
Python tracker
<https://bugs.python.org/issue35377>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35377] urlsplit scheme argument broken
Steven D'Aprano added the comment: You haven't given a convincing reason that there is a problem that needs fixing, or if there is, that your patch is the right way to fix it. You have already pointed out that there is at least one scheme where :/// is part of a valid URL: "file:///". Where there is one, there could be others, if not today, then in the future: spam:///eggs.cheese There are well over 200 registered schemes: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml I don't think it will be practical to put in a whitelist or a blacklist of schemes that are, or aren't, permitted to include :/// after the scheme. It is the caller's responsibility to use the correct scheme, without adding extra characters to the end. I asked you to justify why this should be considered a bug in the library, rather than a bug in your code. I'm not an expert on URLs, but the functions look correct to me. If you can't justify why this is a bug in the library that needs fixing, rather than user-error, we should close this or change it to a request for better documentation. -- ___ Python tracker <https://bugs.python.org/issue35377> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35382] Something wrong with pymysql
Steven D'Aprano added the comment: Also, for future reference, please spend the time to make a good bug report, showing the minimum code needed to reproduce the error, and the full error, not just a summary. Please read this before your next bug report: http://sscce.org/ Thank you. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue35382> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35377] urlsplit scheme argument broken
Steven D'Aprano added the comment: I don't think this is broken, but I do think it could be documented better. You have to read the documentation for `urlparse` to see this: [Quote] Following the syntax specifications in RFC 1808, urlparse recognizes a netloc only if it is properly introduced by ‘//’. Otherwise the input is presumed to be a relative URL and thus to start with a path component. https://docs.python.org/3/library/urllib.parse.html#urllib.parse.urlparse so the function is correct. You're making two errors: - providing a relative URL "httpbin.org" and expecting it to be treated as an absolute URL; - specifying scheme+delimiter instead of the scheme alone. So I don't think this is a bug. urlsplit rightly accepts any arbitrary string as a scheme (it used to have a whitelist of permitted schemes, and that was a problem), and we can't assume that :/// is ONLY valid for file protocols. Unless you come up with a convincing argument for why this is a bug, I'm going to change it to a documentation issue. The docs could do with some improvement to make it more clear, although the examples are good. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue35377> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34850] Emit a syntax warning for "is" with a literal
Steven D'Aprano added the comment: Looks like we have a stand-off between core devs, and no BDFL to make a ruling. There is support for the feature from at least Barry and Raymond (although I think Guido was cool on the idea, maybe?). Gregory, do you feel strongly enough about this that you would reverse the commit if Serhiy just went ahead and committed it? Nobody wants a revert war :-) To me, this seems like a low-cost feature that will help some developers without inconveniencing anyone. As Serhiy points out, SyntaxWarning is only emitted when the code is compiled, so it is only going to be visible to the developer of the module, not the user of the module. Let's not allow the perfect be the enemy of the good enough. I think this is a helpful feature for developers, and as Raymond says it will help teach beginners the difference between `is` and equality. The people who are most prone to making this mistake are the ones least likely to be using a linter. And we know it is helpful: Serhiy already used it to find a bug in IDLE. Gregory, you wanted to close this as not a bug, but nobody says it is a bug, it is an enhancement. And I think there is consensus that this *is* an enhancement. Nobody has said that there are good use cases for using `is` on literals in production code. -- ___ Python tracker <https://bugs.python.org/issue34850> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35340] global symbol "freegrammar" should be made static ore renamed
Steven D'Aprano added the comment: What "freegrammar" symbol are you referring to? Why should it be made static or renamed? 2.7 is something like a decade old now, why do you describe this as a new symbol? -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue35340> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35339] Populating instances of class automatically
Change by Steven D'Aprano : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue35339> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35200] Make the half-open range behaviour easier to teach
Steven D'Aprano added the comment: Raymond: > I'm in agreement with the comments that the proposed __str__ revision is > confusing. In what way is it "confusing"? I'm especially perplexed that Julien apparently thinks it is confusing when emitted by str(), but educational and useful when emitted by repr(). This makes no sense to me. I think Julien's idea is a good one, just not for repr, and I don't think it is confusing at all. Raymond: > most other iterators can't show a preview of the output without actually > consuming some of their inputs `range` is not some arbitrary iterator, in fact it isn't an iterator at all: py> r = range(10) py> iter(r) is r False It is a sequence, like list and tuple, and like list and tuple it is perfectly capable of showing its content (in full or part) on demand. Other important built-in sequence types like strings, lists and tuples aren't hamstrung with the restriction not to do anything iterators can't do, there's no good reason for range objects to be given that restriction. Julien: > I'm closing this. Not so hasty, please. Some of us think this is a worthwhile enhancement. You might have changed your mind, but the idea is bigger than you now :-) I'm taking this discussion to Python-Ideas to see if there is community interest in this feature. If so, I'm going to reopen the issue. -- ___ Python tracker <https://bugs.python.org/issue35200> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35200] Make the half-open range behaviour easier to teach
Steven D'Aprano added the comment:
On Sun, Nov 18, 2018 at 10:27:11PM +, Julien Palard wrote:
>
> Julien Palard added the comment:
>
> If I understand correctly, you'd like str(range(10)) to return " [1, 2, ..., 8, 9]>"?
Exactly the same as you suggested for repr(range(10)) to return, so yes.
> I'm really unconfortable doing this, for me __str__ is here to return
> an “informal or nicely printable string representation of an object",
I think that the output you suggested is an informal AND nicely
printable string representation of the object. In what way do you think
it fails?
It's an *informal* representation in the sense that it doesn't mimic the
range constructor, you can't evaluate it, it isn't even legal Python
syntax.
"Nicely printable" is a matter of taste, but I think its quite nice
(just not suitable for use as the repr), and especially nice for the
purpose of showing the kind of object we're dealing with, rather than
just the values in it.
> not a convoluted "<{type(object)} object ...>" notation.
If this is too convoluted for str(), why is it suitable for beginners
when it goes through repr() instead?
> I agree with you, the [0, 1, ..., 8, 9] notation is too confusing with
> the repr of a list, that's why I proposed the "0, 1, ..., 8, 9" which
> looks nice.
Except that it gives no clue that it is a range object, and fails for
empty ranges.
--
___
Python tracker
<https://bugs.python.org/issue35200>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35274] Running print("\x98") then freeze in Interpreter
Steven D'Aprano added the comment: I'm afraid I can't reproduce that in Python 3.5.2 or 3.6.4. Can you try this? from time import time print(time(), '\x98', time()); print(time()) and copy and paste the results. What terminal/console are you using? If you change to a different console, does the problem go away? -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue35274> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35200] Make the half-open range behaviour easier to teach
Steven D'Aprano added the comment: On Sun, Nov 18, 2018 at 09:43:02PM +, Julien Palard wrote: > My first though went to giving something really simple like: > > >>> print(range(10)) > 1, 2, ..., 8, 9 -1 Surely that would be your *second* thought, since you already had a perfectly adequate first thought: is explicit about what kind of object we have. Remember, there will be times where people don't know they have a range object, and are printing it to find out what they have. Let's just move that from __repr__ to __str__. > But for the empty range it would give an empty string. It may make > sense, but may also be surprising. > > The other way would be to print [1, 2, ..., 8. 9], so the empty range gets [] > instead of nothing. Certainly not. That looks like a list containing 1, 2, ellipsis, 8, 9, and will only increase confusion about the difference between lists and range objects. -- ___ Python tracker <https://bugs.python.org/issue35200> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35256] The Console of Python 3.7.0.
Steven D'Aprano added the comment: I don't understand what you think is the bug. You keep repeatedly appending 'z' to the same list. Why are you surprised that it appends 'z' more than once? If you don't want to append it twice, don't call the function twice. Every time you call the function, it adds another 'z'. That's what the function does. It is working correctly. Can you explain what you think is the bug, because it looks to me like it is working as intended. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue35256> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35245] list comprehension for flattened or nested list differ too much
Steven D'Aprano added the comment: > l2 = [str(leaf) for leaf in tree for tree in forest] Expanded to nested loops, that becomes: l2 = [] for leaf in tree: for tree in forest: l2.append(str(leaf)) which of course gives a NameError, because you are trying to iterate over a tree that you haven't defined yet. The correct way to write this nested comprehension is to put the loops in the same order that they will appear in a nested loop: [str(leaf) for tree in forest for leaf in tree] There are thousands, or more, of nested comprehensions using the existing order in code around the world, if we swapped to your proposed "backwards" order it would change the meaning of their code and break it. That's not going to happen without an excellent reason. I'm closing this "rejected". If you want to debate this and push for the proposed change, you should discuss it on the Python-Ideas mailing list first. -- nosy: +steven.daprano resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue35245> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35224] PEP 572: Assignment Expressions
Change by Steven D'Aprano : -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue35224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35221] Enhance venv activate commands readability
Steven D'Aprano added the comment: https://docs.python.org/3/library/venv.html > my students are often confused by it, sometimes they copy the angle brackets, > sometime even the prompt. Learning to recognise placeholders and the prompt is an essential part of learning to code, and a stage that everyone has to go through. Replacing plain text markup with styled formatting doesn't change that, but it does make it harder for the blind or visually impaired who are using screen-readers, or those who prefer to use a plain text interface with no support for bold/italic. How do your enhancements look in w3m, links or linx? The current design renders nicely in plain text on links. (I haven't checked the other two.) > I ran a few tests. What sort of tests? Usability tests? What results did you get? > Someone on #python-fr proposed > https://framapic.org/XnBQZcJVRlZw/F05D7I8nSKd0.png Link doesn't work for me. I get a blank page. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue35221> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35200] Range repr could be better
Steven D'Aprano added the comment: > I've never seen any student try `str(range(10))` in the repl I never suggested that students would try calling str() directly. That would be silly. They would use print(), as I'm sure many of them are already doing. After 20+ years of using Python, I still sometimes use print in the interactive interpreter when I don't need to. > they all naturally try the bare `range(10)` and they're all presented > with un-informative information. It isn't un-informative information. Its very informative, and useful, but perhaps not the information you are trying to teach your students *at that moment*. But they will have potentially decades of use of Python, long after they have learned that range() is half-open, and the long form is no longer necessary, and perhaps even an annoyance. (It certainly annoys *me*. The existing short form is usually better for my needs, and I think I'm more representative of the average Python coder over their career than beginners during their first few weeks.) > As for repr(range(0)) == repr(range(2, 2)) == repr(range(1, 5, -1)) I > do not consider this a bug I didn't say it was a bug. But it reduces the utility of the display, as you cannot tell the difference between any two empty range objects. And that can be important when trying to work out why your range object is unexpectedly empty. > I don't really agree that changing the repr could break code doing > `eval(repr(range(10)))`, That's not something up for debate. Whether you "really agree" or not, it is a fact that your proposed repr is not legal Python code and therefore it will break code doing eval() on it. > is it really something people do? It is a backwards-incompatible change of behaviour, therefore we must assume it will break someone's code and treat it as a major change. That's not to say that we can't change the repr, but we don't do it lightly. Personally, making a change for the sake of beginners during their first few weeks of learning the language, but inconveniences them for the remaining 95% of their career as a Python coder, does not sound like a good trade-off to me. That's why I suggest that print(range_obj) is a good compromise. Lots of beginners already do this, and for those who don't, print is a good diagnostic tool which they should be taught early. And yes, changing the __str__ is a backwards-incompatible change too, but the potential negative consequences are smaller and the work-arounds are easier. -- ___ Python tracker <https://bugs.python.org/issue35200> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35200] Range repr could be better
Steven D'Aprano added the comment: With the proposed design, any two empty range objects have the same repr: repr(range(0)) == repr(range(2, 2)) == repr(range(1, 5, -1)) etc. Between this loss of information, and the loss of round-tripping through eval, I'm against this proposal. But I'd perhaps be in favour of it as the __str__ rather than __repr__, so that printing a range object displays in the proposed format. By the way, the ``dumb_range_repr`` function in the PR could be simplified: # untested def dumb_range_repr(r): if len(r) < 5: return f"" else: return f"" -- ___ Python tracker <https://bugs.python.org/issue35200> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35200] Range repr could be better
Steven D'Aprano added the comment: Not everyone knows the '...' convention. At least according to Google's predictive search, if I type "what does three dots" I get common searches such as "what does three dots mean at the end of a sentence" and similar. How does your proposed repr look for the edge-cases where there are fewer than five included values? e.g. range(0). -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue35200> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35176] for loop range bug
Steven D'Aprano added the comment: This is not a bug, this is standard behaviour, working as designed. 'a' is not a copy of the list 'x', 'a' is another name for the same list as 'x'. Any in-place modifications you make to 'a' happens to the object itself, the list, which is visible regardless of which name you refer to it by. If you are a C programmer, you can think of this as being similar to pointers: think of 'x' as a pointer to the list, and 'a' as a pointer to the same list. (That's more or less what happens under the hood.) From the Python level, we say that both names 'a' and 'x' refer to the same object. If you want a copy, you can use the copy module, or for lists, you can take a slice: a = x[:] makes a copy of the list. For immutable objects like strings, you don't need a copy, because you cannot modify them in place: any operation on a string always creates a new string, leaving the old one untouched. -- nosy: +steven.daprano resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue35176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35166] BUILD_MAP_UNPACK doesn't function as expected for dict subclasses
Steven D'Aprano added the comment: How weird... after restarting the interpreter, I can't reproduce that TypeError. I get the AssertionError Serhiy showed. -- ___ Python tracker <https://bugs.python.org/issue35166> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35166] BUILD_MAP_UNPACK doesn't function as expected for dict subclasses
Steven D'Aprano added the comment:
You say it doesn't work as expected, but you don't say what you expect or why.
(Don't make me guess what you mean -- explicit is better than implicit.)
When I try your subclass in 3.6, I get an unexpected TypeError:
py> class Dict(dict):
... def keys(self): assert 0
... def update(*args, **kwds): assert 0
... def __getitem__(self, key): assert 0
... def __iter__(self): assert 0
...
py> {**Dict(a=1)}
{'a': 1}
py> Dict(a=1).keys()
Traceback (most recent call last):
File "", line 1, in
File "", line 2, in keys
TypeError
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issue35166>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35165] Possible wrong method name in attribute references doc
Steven D'Aprano added the comment: https://docs.python.org/3/reference/expressions.html#attribute-references __getattr__ is the correct method to override in most (but not all) cases. I don't think we should encourage people to override __getattribute__ as the first resort. __getattribute__ is a more specialised method that is used by the interpreter at a deeper level. It is called on every attribute access, so it ought to be as fast as possible, while __getattr__ is only called if the named attribute doesn't exist. I don't think anything needs to change here. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue35165> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35146] Bad Regular Expression Broke re.findall()
Steven D'Aprano added the comment: This is not a bug in Python, it is an invalid (broken) regular expression. There is nothing that the interpreter or the regular expression engine can do, because you are telling it to do something that makes no sense. What do you expect findall to find, if you ask it to find something nonsensical? You say: "repeat this pattern any number of times" but there is no "this pattern" to be repeated. You are asking for something impossible. The only legitimate response is to report back that the regular expression is invalid and cannot be compiled, and fail immediately. -- nosy: +steven.daprano resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue35146> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35124] Add style guide for unit tests
Steven D'Aprano added the comment: I think this is being excessively prescriptive and solving a problem that isn't a problem. But perhaps if you start by proposing a concrete style guide, I can judge better. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue35124> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35123] Add style guide for sentinel usage
Steven D'Aprano added the comment: I was not aware that there currently were arguments about the use of sentinels in future code. I feel that you are being excessively prescriptive here: "we should nip it in the bud" is good advice for gardening, but for programming it just results in a lot of pre-emptive arguments about prescriptive rules that aren't needed. What makes a sentinel a sentinel is *how it is used*, not what it is. As such, sentinels are just another type of (pseudo-)constant, and the same style guides should apply: in general, they should be in UPPER case, at the top of the module. (But remember the rule about foolish consistency.) And each sentinel should be reused exactly as often as is appropriate. The same as any other constant. As for exposing sentinels, the same applies to any part of the implementation. Should we make this a public part of the API or a private implementation detail? That has to be judged on a case-by-case basis. Making a rule or even a guideline that just because something is a sentinel is "should be" public (or private) is precisely the sort of thing I don't want to see. Sentinels should be public when it makes sense to make them public and private when it makes sense to keep them as private implementation details. The bottom line is, I don't think we need sentinel-specific rules in the style guide. That would be like adding specific rules for "numeric constants", or specific rules for "constants used by decorators". -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue35123> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35129] Different behaviour comparing versions (distutils.version.LooseVersion) between python2.7 and python3.x
Steven D'Aprano added the comment:
There is no need to split the relevant code into a third-party website,
especially when it is so small and can be included in-line here.
Python 2.7:
py> import distutils.version
py> distutils.version.LooseVersion('7') > distutils.version.LooseVersion('XP')
False
Python 3.6:
py> import distutils.version
py> distutils.version.LooseVersion('7') > distutils.version.LooseVersion('XP')
Traceback (most recent call last):
File "", line 1, in
File "/storage/python/Python-3.6.4/Lib/distutils/version.py", line 64, in
__gt__
c = self._cmp(other)
File "/storage/python/Python-3.6.4/Lib/distutils/version.py", line 337, in
_cmp
if self.version < other.version:
TypeError: '<' not supported between instances of 'int' and 'str'
(By the way, you appear to have a bug in your sys.excepthook handler. At least
I can't reproduce the ModuleNotFoundError you are getting.)
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issue35129>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35098] Deleting __new__ does not restore previous behavior
Steven D'Aprano added the comment: > Its quite valid to assign to __new__ to replace the behavior of how an > instance is created. Of course it is, and I never argued otherwise. > Finally as for `Color.__x__` assignment, this has nothing to do with > `__slots__` as it is assigning to `Color`, not to an instance of > `Color`. Of course, sorry for the noise. -- ___ Python tracker <https://bugs.python.org/issue35098> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35098] Deleting __new__ does not restore previous behavior
Steven D'Aprano added the comment: I think the real WTF here is that you can write to arbitrary dunder attributes even if they aren't listed in __slots__. py> Color.__NOBODY_expects_the_Spanish_Inquisition__ = "What?" py> Color.__NOBODY_expects_the_Spanish_Inquisition__ 'What?' I think that assigning to Color.__new__ should have failed in the first place. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue35098> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35085] FileNotFoundError: [Errno 2] No such file or directory:
Change by Steven D'Aprano : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue35085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35085] FileNotFoundError: [Errno 2] No such file or directory:
Steven D'Aprano added the comment: What do you mean, a crash report? You get a traceback telling you the problem: the file is missing. What behaviour did you expect if you try to decode a non-existent file? Perhaps you meant to write: python3 -m base64 -t "12s345a2" I don't think this is a bug, I think it is working correctly. If you cannot explain why it is a bug, we'll close this bug report. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue35085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35069] Unexecuted import in function causes UnboundLocalError
Steven D'Aprano added the comment: Yes, that's exactly right. That's how local variables work in Python: x = 999 # global x def demo(): if False: x = 1 x # local x has no value does the same thing. This is standard, documented behaviour, regardless of which kind of assignment statement you use. -- ___ Python tracker <https://bugs.python.org/issue35069> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35069] Unexecuted import in function causes UnboundLocalError
Steven D'Aprano added the comment: Stéphane, I'm curious why you asked for a pastebin when James already provided the code right here in the tracker? (Your email even included a copy of that code.) Why split the information into another website? -- ___ Python tracker <https://bugs.python.org/issue35069> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35069] Unexecuted import in function causes UnboundLocalError
Steven D'Aprano added the comment: This is expected behaviour: import is a form of assignment. "import logging", like "logging = 1", tells the compiler to treat logging as a local variable (unless you declare logging as global). As the exception says, you are trying to access the logging local variable before it has been assigned to. You can (and should!) give a SHORT and SIMPLE demonstration, without any excess and irrelevant code: py> def demo(): ... if False: ... import logging ... logging ... py> demo() Traceback (most recent call last): File "", line 1, in File "", line 4, in demo UnboundLocalError: local variable 'logging' referenced before assignment So this is expected behaviour. -- nosy: +steven.daprano resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue35069> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35010] sort by partially reversed key tuple
Steven D'Aprano added the comment: > And you are free to use whatever sorting algorithms in its implementation for > this kind of task. That's very kind of you *wink* At this point, I don't think there's much more point to discussing this further until Tim Peters weighs in and lets us know what he thinks. If he loves the idea, and is able to implement it, it may happen; if he is luke-warm or hates it, probably not. (My own *personal* view is that unless there is an obvious and consistent performance win from adding this, adding the extra complexity to both the sort implementation and the interface isn't worth the effort. Not every simple helper function needs to be a builtin.) -- ___ Python tracker <https://bugs.python.org/issue35010> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35010] sort by partially reversed key tuple
Steven D'Aprano added the comment: The ``sorted`` docs links to the Sorting HOWTO, the ``list.sort`` docs should do the same. https://docs.python.org/3/library/functions.html#sorted https://docs.python.org/3/library/stdtypes.html#list.sort -- ___ Python tracker <https://bugs.python.org/issue35010> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35010] sort by partially reversed key tuple
Steven D'Aprano added the comment: Since sort is guaranteed to be stable, can't you sort in two runs? py> values = ['bc', 'da', 'ba', 'abx', 'ac', 'ce', 'dc', 'ca', 'aby'] py> values.sort(key=itemgetter(1), reverse=True) py> values.sort(key=itemgetter(0)) py> values ['ac', 'abx', 'aby', 'bc', 'ba', 'ce', 'ca', 'dc', 'da'] Its not as efficient as doing a single sort, but its easier to understand than a complex API to specify each item's sort direction individually, and therefore probably less likely to mess it up and get it wrong. -- nosy: +steven.daprano, tim.peters ___ Python tracker <https://bugs.python.org/issue35010> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34991] variable type list [] referential integrity data loss
Steven D'Aprano added the comment: I don't know what you mean by "referential integrity data loss". I have absolutely no idea how to interpret the wall of output you have provided. If there is a bug here, how do you know it is a language bug rather than a bug in your own code? We're not here to debug your code for you, especially when the code you provide is incomplete (what's Graph.isGoal?) and not the code you are actually running. There is no print inside the visitedPath function, so how are you getting the output checkvisit "inside def(visitedPath)" as you say? If there is one difference between the code you run and the code you send us, there could be a hundred differences. Please provide a *minimal* example of the problem, showing clear input, expected result, and actual result. You might find it helpful to read this page first: http://sscce.org/ It is written for Java programmers, but the advice applies equally to Python too. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue34991> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34948] Document __warningregister__
Steven D'Aprano added the comment: On Wed, Oct 10, 2018 at 05:11:01AM +, Serhiy Storchaka wrote: > I don't think that it is necessary to state its format. It is an > opaque dictionary, and its format is an implementation detail. There is at least one use-case for wanting to manipulate the registry: https://redd.it/9mqb45 -- ___ Python tracker <https://bugs.python.org/issue34948> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34948] Document __warningregister__
New submission from Steven D'Aprano : The warnings module makes use of a per-module global ``__warningregister__`` which is briefly mentioned in the docs but not documented. https://docs.python.org/3/library/warnings.html#warnings.warn_explicit Given that it is part of the warn_explicit API, we should accept that the registry file is now part of the public API not just an implementation detail, and so we should explicitly document its existence and state the expected format. -- components: Library (Lib) messages: 327449 nosy: steven.daprano priority: normal severity: normal status: open title: Document __warningregister__ type: behavior ___ Python tracker <https://bugs.python.org/issue34948> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34928] string method .upper() converts 'ß' to 'SS' instead of 'ẞ'
Steven D'Aprano added the comment: We match the Unicode specification, not arbitrary language rules. (Austrian and Swiss German are, I believe, phasing out ß altogether, and haven't added an uppercase variant.) Until the Unicode consortium change their case conversion rules, it is still correct for .upper() to convert 'ß' to 'SS'. The eszett is just one of the many annoying anomalies in case conversion, like Turkish dotted and dotless i. Natural language is hard, and messy. http://unicode.org/faq/casemap_charprop.html -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue34928> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28716] Fractions instantiation revisited
Change by Steven D'Aprano : -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue28716> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33084] Computing median, median_high an median_low in statistics library
Steven D'Aprano added the comment: I want to revisit this for 3.8. I agree that the current implementation-dependent behaviour when there are NANs in the data is troublesome. But I don't think that there is a single right answer. I also agree with Mark that if we change median, we ought to change the other functions so that people can get consistent behaviour. It wouldn't be good for median to ignore NANs and mean to process them. I'm inclined to add a parameter to the statistics functions to deal with NANs, that allow the caller to select from: - implementation-dependent, i.e. what happens now; (for speed, and backwards compatibility, this would be the default) - raise an exception; - return a NAN; - skip any NANs (treat them as missing values to be ignored). I think that raise/return/ignore will cover most use-cases for NANs, and the default will be suitable for the "easy cases" where there are no NANs, without paying any performance penalty if you already know your data has no NANs. Thoughts? I'm especially looking for ideas on what to call the first option. -- assignee: -> steven.daprano versions: +Python 3.8 -Python 3.6 ___ Python tracker <https://bugs.python.org/issue33084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22232] str.splitlines splitting on non-\r\n characters
Steven D'Aprano added the comment: I don't like the idea of adding a second bool parameter to splitlines. Guido has a rough rule of thumb (which I agree with) of "no constant bool parameters". If people will typically call a function with some sort of "mode" parameter using a hard-coded bool, then we should usually prefer to split the two modes into distinct functions. As an example, we have statistics.stdev and pstdev rather than stdev(data, population=False). Obviously this is a guideline, not a hard rule, and there are exceptions. Such as str.splitlines :-) In any case, I suggest a separate string method. Even though the name is slightly inaccurate, I suggest "ascii_splitlines" which I think is accurate enough to capture the spirit of what we intend (split on *only* \n \r and \r\n) and we can leave the details in the docs. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue22232> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34907] calculation not working properly
Steven D'Aprano added the comment: For future reference, please don't post unnecessary screen shots and images. Code is text, please copy and paste it as text, not as pixels. Images make it difficult or impossible for the blind and visually impaired to contribute. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue34907> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34880] About the "assert" bytecode
Steven D'Aprano added the comment: > And, I think a broader discussion on python-dev might be useful, too, in > order to get more opinions. Done: https://mail.python.org/pipermail/python-dev/2018-October/155410.html Changing the status to Pending until we have more clarity on whether this is a bug, feature, accident or whatnot. -- resolution: not a bug -> stage: resolved -> status: closed -> pending ___ Python tracker <https://bugs.python.org/issue34880> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34880] About the "assert" bytecode
Steven D'Aprano added the comment: On Wed, Oct 03, 2018 at 01:56:00PM +, Eric V. Smith wrote: > I think this is a bug that should be fixed. Supporting this position, shadowing other exceptions doesn't change the exception generated by the interpreter: py> TypeError = None py> 1 + "a" Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for +: 'int' and 'str' On the other hand, this has been the behaviour going back to Python 1.5, it is hard to see why this is worse than any other example of shadowing. I don't think there's anything in the documentation that says that assert *shouldn't* do a LOAD_GLOBAL on AssertionError. Hence this would be an enhancement rather than a bug fix. > And, I think a broader discussion on python-dev might be useful, too, > in order to get more opinions. I agree. I think we need to clarify the intent here, and then decide that if it is a bug, should we bother fixing it in pre-3.8 versions? -- ___ Python tracker <https://bugs.python.org/issue34880> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34880] About the "assert" bytecode
Steven D'Aprano added the comment:
On Wed, Oct 03, 2018 at 09:49:06AM +, thautwarm wrote:
> Steven, this problem is quite interesting because it just allows users
> to cause fatal errors without any invalid operations.
How is that different from every other case of shadowing a builtin?
len = 45
print(len("hello world"))
The ability to shadow builtins is a feature, not a bug.
I have no specific objection to changing assert so that it raises the
actual honest-to-goodness AssertionError, but that would be an
enhancement, not a bug-fix.
(To be honest, that's what I assumed it would do, until I tried it.)
--
___
Python tracker
<https://bugs.python.org/issue34880>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34880] About the "assert" bytecode
Steven D'Aprano added the comment: If I have understood you correctly, you are asking whether it is expected behaviour for assert to use the global AssertionError instead of the built-in AssertionError. I don't see why it shouldn't. In any case, that behaviour goes back to Python 1.5 and perhaps older. I don't think this is a bug, so I'm going to close this. If you disagree, please re-open it with more detail explaining why you think it is a bug. -- nosy: +steven.daprano resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34880> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34850] Emit a syntax warning for "is" with a literal
Steven D'Aprano added the comment: Please move the "chaos" discussion to #34867 -- ___ Python tracker <https://bugs.python.org/issue34850> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34867] Add mode to disable small integer and interned string caches
New submission from Steven D'Aprano : Split off from #34850 by Guido's request. To help catch incorrect use of `is` when `==` is intended, perhaps we should add an interpreter mode that disables the caches for small ints and interned strings. Nathaniel called it "chaos mode" but I don't like the name as there is nothing chaotic about the lack of such caches, and it doesn't come close to chaos testing (e.g. Netflix's Chaos Monkey tool). -- components: Interpreter Core messages: 326838 nosy: gregory.p.smith, njs, steven.daprano priority: normal severity: normal status: open title: Add mode to disable small integer and interned string caches versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue34867> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34850] Emit a syntax warning for "is" with a literal
Steven D'Aprano added the comment:
On Sun, Sep 30, 2018 at 10:24:41PM +, Nathaniel Smith wrote:
> Would it make sense to implement a "chaos" mode (that e.g. testing
> tools could enable unconditionally), that disables the small integer
> and small string caches?
I'm not really sure that "chaos" is a good name for that. Contrast
the rather restricted scope ("disable caches") with this example of
chaos:
https://en.wikipedia.org/wiki/Chaos_Monkey
--
___
Python tracker
<https://bugs.python.org/issue34850>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34850] Emit a syntax warning for "is" with a literal
Steven D'Aprano added the comment: I like this solution of a syntax warning for `is ` and I agree that `== None` should not be a warning. (And for what its worth, I strongly disagree with making `is` a hybrid sometimes-check-identity-sometimes-check-equality operator.) -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue34850> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34835] Multiprocessing module update fails with pip3
Steven D'Aprano added the comment: ``pip3 search multiprocessing`` says: multiprocessing (2.6.2.1)- Backport of the multiprocessing package to Python 2.4 and 2.5 so you are trying to install a Python 2.4/2.5 package into Python 3.7, which naturally cannot work. In Python 2.6+ multiprocessing is a std lib module and you don't need to use pip to install it. I'm not sure if pip works with Python 2.4 or 2.5, but if it does, you'll need to use the 2.4/2.5 version of pip to do the update, not pip3. I'm going to close this as not a bug. If you disagree, please give reasons why you think it should be reopened. -- nosy: +steven.daprano resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34835> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34763] Python lacks 0x4E17
Change by Steven D'Aprano : -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue34763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34709] Suggestion: make getuser.getpass() also look at SUDO_USER environment variable
Steven D'Aprano added the comment:
Versions 3.7 and below are all in feature-freeze, so this change could only
apply to 3.8 and above.
I don't know if this feature is desirable or not.
If it is (sometimes?) desirable, my guess is that it would be undesirable to
use SUDO_USER *unless* the effective user ID was 0. (Don't check for the name
"root", that's only a convention.) In pseudocode:
names = ('LOGNAME', 'USER', 'LNAME', 'USERNAME')
if effective user ID == 0:
names = ('SUDO_USER',) + names
for name in names:
...
Also needs documentation and tests.
--
nosy: +steven.daprano
versions: -Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue34709>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34645] math and numpy yield different results (nan)
Steven D'Aprano added the comment: > Well, the thing is that i pass two (apparent) identical values into the same > function, Even if they have the same *numeric* value, they aren't the same kind of value, and they aren't the same function. One is and the other is . When you call ** (exponentiation), that calls two different methods. One raises a warning and returns NAN, the other converts to complex. This has nothing to do with linspace. See my simplifed example code which doesn't use it. -- ___ Python tracker <https://bugs.python.org/issue34645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34645] math and numpy yield different results (nan)
Steven D'Aprano added the comment: Oops, sorry, I mistyped. I said: So there's a problem. You're trying to raise a negative number to a positive value I meant to say a *fractional* value. Sorry for the confusion. -- ___ Python tracker <https://bugs.python.org/issue34645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34645] math and numpy yield different results (nan)
Steven D'Aprano added the comment:
Your code gives runtime warnings of invalid values. You should fix that. If
your values are invalid, there's probably a bug in your code.
RuntimeWarning: invalid value encountered in double_scalars
Your code is also very complex. You ought to simplify the example so that it is
easier to understand, all the business with linspace and duplicated code just
adds complexity and makes it hard to understand.
I simplified your code to this:
import numpy as np
n=2.758
n2 = 2.0 / n
ct = np.cos(2 * np.pi * 2.0 / 5)
print("numpy", ct, abs(ct ** n2) * 5.0)
which gives this output:
__main__:1: RuntimeWarning: invalid value encountered in double_scalars
('numpy', -0.80901699437494734, nan)
So there's a problem. You're trying to raise a negative number to a positive
value, and numpy doesn't like it and returns a NAN.
But using the standard math library, raising a negative number to a positive
value gives you a complex number:
ct = math.cos(2 * math.pi * 2.0 / 5)
print(ct**n2)
print("math", ct, abs(ct ** n2) * 5.0)
which gives this output:
(-0.5572617094280153+0.6517928032447587j)
math -0.8090169943749473 4.287698890886272
So the behaviour is correct and this is not a bug in either math nor numpy.
They're just doing different things.
--
nosy: +steven.daprano
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue34645>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34644] Bug in reverse method
Steven D'Aprano added the comment: This is not a bug or a syntax error, and the behaviour goes back to at least Python 1.5 if not older. List.reverse returns a reference to the method object itself. List.reverse() *calls* the method. This is standard behaviour in Python, all methods and functions are first-class values, anything you can do with an object, you can do with a function or method too. For example: py> list.reverse.__name__ 'reverse' py> print(len) py> alist = [1, "a", chr] py> print(alist) [1, 'a', ] -- nosy: +steven.daprano resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34644> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34596] [unittest] raise error if @skip is used with an argument that looks like a test method
Steven D'Aprano added the comment: For what its worth, I'm +1 with Serhiy that we raise an exception on a non-string argument, including the case where the caller forgets to provide a reason at all. I don't think that @skip with no reason was ever intended to work (it certainly wasn't documented as working) and as this only effects tests, not production code, I don't think we ought to be constrained by "bug compatibility" concerns. Fixing broken tests is easier than fixing broken production code. -- ___ Python tracker <https://bugs.python.org/issue34596> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34605] Avoid master/slave terminology
Steven D'Aprano added the comment: I strongly disagree with this as a general principle. "Master/slave" is a powerful, obvious metaphor which works well and is not the same as parent/child, server/client or employer/worker. In fact, in the BDSM subcultures, "master/slave" can have *positive* connotations. You want to support diversity, then why are you discriminating against that subculture? Talking about diversity: my wife is of a nationality that historically were often stolen to be slaves and indentured servants, and were discriminated against as second-class people right well into the second half the middle of the 20th century. My maternal family comes from a racial group (Slavic) which gives us the English word for slave and come from serf background. Both of us are angered by this attack on our linguistic culture. Stop trying to sanitize and infantalize language. That's far more offensive than the master/slave terminology. I'm not sorry for this impassioned plea. You want diversity, that includes people like me. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue34605> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34596] [unittest] raise error if @skip is used with an argument that looks like a test method
Steven D'Aprano added the comment: Is there a use-case for reason to be anything but a string? -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue34596> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34543] _struct.Struct: calling functions without calling __init__ results in SystemError
Steven D'Aprano added the comment: Thanks for confirming the seg fault. I've changed this to a crasher. Should we change the exception to RuntimeError? -- components: +Library (Lib) -Extension Modules type: behavior -> crash ___ Python tracker <https://bugs.python.org/issue34543> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34543] _struct.Struct: calling functions without calling __init__ results in SystemError
Steven D'Aprano added the comment: I've tried running this code in Python 3.6: from _struct import Struct for i in range(10): L = [Struct.__new__(Struct) for j in range(1000)] for s in L: try: x = s.pack_into(bytearray()) except SystemError: pass I've run it 6 times, for a total of 600 million calls to Struct.__new__ and pack_into, and I cannot reproduce any crash or segfault. An exception (SystemError) is the correct behaviour. Is anyone able to try it under Python 3.7? Unless somebody is able to demonstrate a segfault or core dump, or otherwise demonstrate a problem with the C code, I think this ticket ought to be closed. -- ___ Python tracker <https://bugs.python.org/issue34543> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34543] _struct.Struct: calling functions without calling __init__ results in SystemError
Steven D'Aprano added the comment: _struct is a private implementation detail. You shouldn't use it. You shouldn't care where the implementation "really is" in your Python code, because it could move without warning. There are no backwards-compatibility guarantees for private modules like _struct. But regardless of where you are importing it from, why are you calling Struct.__new__(Struct) in the first place? You should be calling Struct(). I still don't see any reason to consider this a bug. I can't reproduce your report of a crash: py> from _struct import Struct py> s = Struct.__new__(Struct) py> b = bytearray() py> s.pack_into(b) Traceback (most recent call last): File "", line 1, in SystemError: null argument to internal routine I get an exception, which is the correct behaviour. Unless this segfaults, I don't believe this is a bug that needs fixing. (By the way, Struct doesn't even have a __new__ method. You are calling the __new__ method inherited from object, which clearly knows nothing about how to initialise a Struct.) -- ___ Python tracker <https://bugs.python.org/issue34543> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34543] _struct.Struct: calling functions without calling __init__ results in SystemError
Steven D'Aprano added the comment: This exception goes back to at least Python 2.6 (if not older) but I'm not convinced it is a bug. Calling __new__ alone is not guaranteed to initialise a new instance completely. The public API for creating an instance is to call the class object: s = Struct() not to call __new__. You bypassed the proper initialisation of the instance, resulting in a broken, half-initialised instance. When you tried to use it, it correctly raised an exception. If this caused a crash or a seg fault, then it would be reasonable to report it as a bug, but it looks to me that this is behaving correctly. If you disagree, please explain why you think it is a bug. (Also, for the record, you shouldn't be importing Struct from the private module _struct, you should import it from the public struct module.) -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue34543> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34483] eval() raises NameError: name '...' is not defined
Change by Steven D'Aprano : -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue34483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34437] print statement using \x results in improper and extra bytes
Steven D'Aprano added the comment:
You wrote:
> There are 6 bytes not 4 and where did the c3, bd, and c2 come from?
In Python 2, strings are byte strings, in Python 3, strings by default are
Unicode text strings. You are seeing the UTF-8 representation of the text
string.
py> "\xfd\x84\x04\x08".encode('utf-8')
b'\xc3\xbd\xc2\x84\x04\x08'
So the behaviour in Python 3 is correct and not a bug, it has just changed
(intentionally) from Python 2.
Googling may help you find more about this:
https://duckduckgo.com/?q=python3+write+bytes+to+stdout
--
nosy: +steven.daprano
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue34437>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34358] round() combined with product outputs ugly result
Change by Steven D'Aprano : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34358> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34346] dir() hangs interpreter
Steven D'Aprano added the comment: I don't think the description you give is very accurate. The description in the file splat.py says: "Hangs/core dumps Python2 when instantiated" (which is it? hang or core dump?) but I can't replicate that. Instantiating A() is fine for me. (Tested in Python 2.7 on Linux.) The whole business about "splat" is amusing but irrelevant. I can replicate the hang (no core dump) using this simpler example: class B: def __getattr__(self, name): return name in dir(self) Instantiating the class is fine, but calling dir() on it locks up: >>> b = B() >>> dir(b) [1]+ Stopped python2.7 -E (after typing Ctrl-Z in the xterm). Notice that B is an old-style class in this example. The same behaviour also occurs when inheriting from object. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue34346> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34039] Loop limited to 1000
Steven D'Aprano added the comment: Sorry, this is for reporting bugs in the Python interpreter and standard library, not your own code. If you have a bug in your pyinator project, you should report it to yourself, not us :-) If you think my analysis of the problem below is wrong, and that you have truly found a bug in the interpreter, please read this: http://www.sscce.org/ and give us the smallest example of this bug you can, don't just link to your library and expect us to find the problem ourselves. My analysis, based on a *brief* look at your project, it that every time you call GetPriceCheck, you increase the recursion limit by an extra 1000, and then keep making more and more recursive calls until you run out of memory and segfault. That's pretty much unavoidable. To prevent that, you can: - add more memory; - make fewer recursive calls; - fix your code to use a better technique for scraping websites. (It is rude to keep hitting a website over and over and over again, without any limit. Websites have limited bandwidth, which they pay for, and every time you hit the website, that makes it harder for somebody else. At the very least, you should back off exponentially, waiting longer between each attempt: 1 second, 2 seconds, 4 seconds, 8 seconds, 16 seconds...) The recursion limit is designed to prevent segfaults by giving you a nice Python-level exception instead of a hard, OS-level segmentation fault. But if you set the recursion limit too high, you by-pass that protection and you are responsible for not crashing the stack. -- nosy: +steven.daprano resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34039> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
