[issue2771] Test issue
Change by Ezio Melotti : -- nosy: -EWDurbin, matrixise, nedbat, pitrou, python-dev, zach.ware resolution: fixed -> works for me ___ Python tracker <https://bugs.python.org/issue2771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2771] Test issue
Ezio Melotti added the comment: So long, and thanks for all the bugs. -- ___ Python tracker <https://bugs.python.org/issue2771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46111] test_unittest fails in optimized mode
Change by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker <https://bugs.python.org/issue46111> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2771] Test issue
Change by Ezio Melotti : -- dependencies: +Add math.tau, Python source code build fails with old mercurial superseder: -> Test issue ___ Python tracker <https://bugs.python.org/issue2771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2771] Test issue
Ezio Melotti added the comment: Testing GitHub mentions, please ignore: @serhiy-storchaka -- ___ Python tracker <https://bugs.python.org/issue2771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2771] Test issue
Change by Ezio Melotti : -- assignee: python-dev -> ezio.melotti ___ Python tracker <https://bugs.python.org/issue2771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2771] Test issue
Change by Ezio Melotti : -- assignee: python-dev -> ___ Python tracker <https://bugs.python.org/issue2771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2771] Test issue
Change by Ezio Melotti : -- assignee: -> python-dev ___ Python tracker <https://bugs.python.org/issue2771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2771] Test issue
Change by Ezio Melotti : -- assignee: ezio.melotti -> python-dev versions: +Python 3.11 -Python 3.9 ___ Python tracker <https://bugs.python.org/issue2771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45532] Replace 'default' with 'main' as default in sys.version
New submission from Ezio Melotti :
sys.version returns '3.10.0 (default, Oct 5 2021, 23:49:26) [GCC 10.2.1
20210110]'
'default' is supposed to represent the name of the branch, and it's been there
since the HG days:
https://github.com/python/cpython/blob/fc64c351c7757f0ebdb7da65cb74871e494a2add/Modules/getbuildinfo.c#L44
When the code was updated for Git in #27593, the default remained the same:
https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79751c/Modules/getbuildinfo.c#L44
The default should be updated to 'main'.
Note that _Py_gitidentifier is supposed to return meaningful values while
building from within a git checkout -- when it fails to do so the default value
is used. This can also be tested through sys._git (which returns ('CPython',
'', '')), but at the moment I can't build from a git checkout and verify that
_Py_gitidentifier returns the correct branch. If not, a separate issue should
be created.
--
components: Interpreter Core
messages: 404380
nosy: ezio.melotti
priority: normal
severity: normal
stage: test needed
status: open
title: Replace 'default' with 'main' as default in sys.version
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9
___
Python tracker
<https://bugs.python.org/issue45532>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43520] Fraction only handles regular slashes ("/") and fails with other similar slashes
Change by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker <https://bugs.python.org/issue43520> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41748] HTMLParser: comma in attribute values with/without space
Ezio Melotti added the comment: Merged! Thanks for the report and the PR! -- assignee: -> ezio.melotti resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue41748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41748] HTMLParser: comma in attribute values with/without space
Ezio Melotti added the comment: New changeset 9eb11a139fac5514d8456626806a68b3e3b7eafb by Karl Dubost in branch 'master': bpo-41748: Handles unquoted attributes with commas (#24072) https://github.com/python/cpython/commit/9eb11a139fac5514d8456626806a68b3e3b7eafb -- ___ Python tracker <https://bugs.python.org/issue41748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42821] HTMLParser: subsequent duplicate attributes should be ignored
Ezio Melotti added the comment:
If we follow the behavior of the browser, we will have to pick one of the two
values and discard the other, making this value unaccessible. If we provide
both, scripts and libraries that use HTMLParser will have access to both and
can decide what to do.
For example BeautifulSoup already does the right thing:
>>> bs4.BeautifulSoup('text')
text
Changing this might also break code that rely on this behavior. I'm therefore
going to close this as "not a bug".
--
assignee: -> ezio.melotti
nosy: +ezio.melotti
resolution: -> not a bug
stage: -> resolved
status: open -> closed
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue42821>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41748] HTMLParser: comma in attribute values with/without space
Ezio Melotti added the comment:
Writing tests that verify the expected behavior is a great first step. The
expected output in the tests should match the behavior described by the HTML 5
specs (which should also correspond to the browsers' behavior), and should
initially fail. You can start creating a PR with only the tests, clarifying
that it's a work in progress, or wait until you have the fix too.
The next step would be tweaking the regex and the code until both the new tests
and all the other ones work (excluding the one with the commas you are fixing).
You can then commit the fix in the same branch and push it -- GitHub will
automatically update the PR.
> Do you have a suggestion to fix it?
If you are familiar enough with regexes, you could try to figure out whether it
matches the invalid attributes or not, and if not why (I took a quick look and
I didn't see anything immediately wrong in the regexes).
Since the output of the failing test is [('data', '')],
it's likely that the parser doesn't know how to handle it and passes it to one
of the handle_data() in the goahead() method. You can figure out which one is
being called and see which are the if-conditions that are leading the
interpreter down this path rather than the usual path where the attributes are
parsed correctly.
If you have other questions let me know :)
--
type: crash -> behavior
___
Python tracker
<https://bugs.python.org/issue41748>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27886] Docs: the difference between rename and replace is not obvious
Change by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker <https://bugs.python.org/issue27886> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41989] htmlparser unclosed script tag causes data loss
Change by Ezio Melotti : -- assignee: -> ezio.melotti nosy: +ezio.melotti ___ Python tracker <https://bugs.python.org/issue41989> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41748] HTMLParser: parsing error
Ezio Melotti added the comment: The html.parser follows the HTML 5 specs as closely as possible. There are a few corner cases where it behaves slightly differently but it's only while dealing with invalid markup, and the differences should be trivial and generally not worth the extra complexity to deal with them. In this case, if I recall correctly, the way the comma is handled is just a left-over from the previous version of the parser, that predates the HTML 5 specs. In tags like there was an ambiguous situation and parsing it was deemed a reasonable interpretation, so the comma was treated as an attribute separator (and there should be test cases for this). This likely caused the issue reported by the OP, and I think it should be fixed, even if technically it's a change in behavior and will break some of the tests. If I'm reading the specs[0] correctly: * should be parsed as , and * should be parsed as , where ',baz' is the attribute name > Also, there is no warning about security in the html.parser documentation? I'm not aware of any specific security issues, since html.parser just implements the parser described by the HTML 5 specs. If there are any security issues caused by divergences from the specs, they should be fixed. I'm not sure why a warning would be needed. > Is this module mature and maintained enough to be considered as reliable? Even though it hasn't been updated to the latest version of the specs (5.2 at the time of writing), it has been updated to implement the parsing rules described by the HTML 5 specs. I don't know if the parsing rules changed between 5.0 and 5.2. > Or should we warn users about possible issues on corner cases, and point to > BeautilfulSoup for a more mature HTML parser? BeautifulSoup is built on top of html.parser (and can also use other parses, like lxml). BS uses the underlying parsers to parse the HTML, then builds the tree and provides, among other things, functions to search and edit it. When I upgraded html.parser to HTML 5 I worked with the author of BeautifulSoup (Leonard Richardson), to make sure that my changes were compatible with BS. We also discussed about some corner cases he found and other feature requests and issues he had with the old version of the parser. That said, a link to BS would be a nice addition, since it's a great library. [0] starting from https://www.w3.org/TR/html52/syntax.html#tokenizer-before-attribute-name-state -- nosy: +ezio.melotti stage: -> test needed ___ Python tracker <https://bugs.python.org/issue41748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41411] Improve and consolidate f-strings docs
Ezio Melotti added the comment: Thanks both for pointing out the additional section in inputoutput.rst that I initially missed. > I have done PR 21681 that adds index to the tutorial although searching[2][3] > does not seem to be better now that the reference has an index. The online docs seem updated, so I'm not sure why it's not working. Maybe you could try moving things around and see if you can make it work? You should be able to build the docs locally and test from there. You can also see if Sphinx raises any warning during the build process, try to move the `.. index` directive just after the section title (instead of before), or add an empty line between the list of entries and the section label (unnecessary if you move the entries after the title). > This is there[0] but it _IS_ hard to find, when you don't know it is there. I noticed (or rather, I didn't :)! > It may not be very "introduction-y", and if you like I can make a go at > trying to reword it. I think this section is fine, the only thing that needs to be update is the link at the end of the section to point to the main f-string section that we will add elsewhere. >> The stdtypes page is already quite long and crowded ... > True. But is this wrong? In my feeling this is reference documentation. It > should be accurate, complete and clear. It may not need to be "textbook-like". You might be right. > Some thoughts: > - There may be benefit in reorganising stdtypes.rst to improve the flow > without changing the actual content. This could mean breaking it up into a > number of documents rather than the monolith it is. Both in the documentation and in the code, there are advantages in having everything on a single page/file (such as easier ctrl+f search) but also disadvantages. Given the goal of the page, I think keeping it monolithic is fine: it provides a summary of all the built-in types in a single place. Breaking it down into multiple pages will have other issues. If you make a page per type, you will have some pages that are very short, and it will be more difficult to get an overview of all the types, comparing them, and searching through all of them at once. > - It does feel like printf[4] was plugged in later because str.format()[5] > had been explained earlier. (Although I believe printf came before > str.format()). A first time reader of the document will find it hard to know > the one way that is right when it comes to formatting. If I recall correctly that section has also been there, but initially it was just describing the standard way of doing string formatting, and when str.format() was added, it got renamed and the note at the top was added to link to the str.format() documentation. I guess that the str.format documentation ended up in string.rst because it was related to string.formatter, and the author wanted to keep them together. > - f-strings should probably also be described here because it _is_ built in, > no? It may not be accurate to say it is in /Lib/strings. There is no > reference that a developer can just look at to remind/confirm to themselves > how to "do it". Agreed, stdtypes.rst would be the right place where to document this, my only concerns were: 1) the size of the page (that as said above, is not such a big deal); 2) keeping str.format() and string.Formatter() together (but this is also not a huge concern). Also note that str.format() is not documented in stdtypes.rst, however there is an entry for str.format() with a clear link to the formatting docs, so I never had a problem finding it, even if I needed an extra click. [...] > But now (and this is mainly to me) it appears that another problem is a need > to consistently, clearly, and in one place describe the various > elements/nuances/eccentricities of presenting data in Python: > - string > - string.Formatter, > - string.Template, > - str.format() > - f-string > - Format Specification Mini-Language > - maybe even __format__ and conversion? > - etc What about doing the following: * keep having stdtypes.rst cover and explain all the built-in types and their features; * move the "Format String Syntax", "Format Specification Mini-Language", "Format examples" sections from string.rst to stdtypes.rst where they belong; * integrate f-strings in these sections, and add a new section explaining f-string-specific quirks; * leave the printf-style string formatting in stdtypes.rst, after the format sections * use string.rst to document the string module and its objects, hence leaving string.Formatter and string.Template here, where they belong (string.Formatter is self contained enough that doesn't need to be with the other format sections); * leave the inputoutput.rst and lexical_analysis pages as
[issue41411] Improve and consolidate f-strings docs
Ezio Melotti added the comment:
HOWTOs are generally used to explain how to accomplish a certain task, so I'm
not sure if they are a good fit for this situation.
In the list of proposed solutions in my first message, 1-3 should be quite easy
to implement. This leaves us with 4-5.
To summarize what we already have (let me know if I missed anything):
* string.rst[0] (the string module):
String constants (string constants)
Custom String Formatting (string.Formatter)
Format String Syntax (explains the syntax of {...})
Format Specification Mini-Language
Format examples
Template strings (string.Template)
Helper functions (string.capwords)
* stdtypes.rst[1] (about Python builtin types):
Text Sequence Type — str (short intro about str)
String Methods (all the str.* methods)
printf-style String Formatting (old %-formatting)
* introduction.rst[2] (the string section in the tutorial)
* lexical_analysis.rst[3]
String and Bytes literals
String literal concatenation
Formatted string literals
The lexical analysis is probably fine as is. The introduction in the tutorial
should mention f-strings, include a couple of examples, and link to the
documentation for more. The stdtypes page is already quite long and crowded,
so I'm wary about adding more stuff in there. So, unless we add a separate
page somewhere, the string page seems the best candidate, even if technically
it should be about the string module.
On top of items 1-3 of my previous message, to solve 4-5 I suggest to:
1) move the printf-style formatting section to string.rst;
2) add a section about f-strings under Format String Syntax in string.rst,
focusing on differences and caveats that are unique to f-strings;
3) add some f-string-specific examples after the format examples
4) mention f-string in the string section of the tutorial, and in the text
sequence type section of stdtypes.rst;
The string.rst page could then look something like:
String constants (string constants)
Custom String Formatting (string.Formatter)
Format String Syntax (explains the syntax of {...})
Format Specification Mini-Language
Format examples
f-strings
f-strings examples
printf-style String Formatting (old %-formatting)
Template strings (string.Template)
Helper functions (string.capwords)
This should consolidate all the docs in two places: string.rst and
lexical_analysis.rst (they have a different target, so the separation is ok).
All other places can then refer to this. Once this is done, we can still
decide to move these out of string.rst.
[0]: https://docs.python.org/3/library/string.html
[1]: https://docs.python.org/3/library/stdtypes.html#textseq
[2]: https://docs.python.org/3/tutorial/introduction.html#strings
[3]:
https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals
--
___
Python tracker
<https://bugs.python.org/issue41411>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41411] Improve and consolidate f-strings docs
Change by Ezio Melotti : -- keywords: +patch pull_requests: +20788 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/21552 ___ Python tracker <https://bugs.python.org/issue41411> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41045] f-string's "debug" feature is undocumented
Ezio Melotti added the comment: > I agree that it might be better to separate them into a new issue. I created #41411. -- ___ Python tracker <https://bugs.python.org/issue41045> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41411] Improve and consolidate f-strings docs
New submission from Ezio Melotti : [Creating a new issue from #41045] I was just just trying to link to someone the documentation for f-strings, but: 1) Searching "fstring" only returns two results about xdrlib[0]; 2) Searching "f-string" returns many unrelated results[1]; 3) The first (and closer) result (string -- Common string operations[2]) yields nothing while using ctrl+f with fstring, f-string, f', f"; 4) at the top of that page there are two links in a "see also": * Text Sequence Type — str[3]: it mentions raw strings at the beginning, but also yields no results for fstring, f-string, f', f"; * String Methods[4]: that is another section of the previous page (so ctrl+f doesn't find anything), but has a link to "Format String Syntax"[5]; 5) The "Format String Syntax" page[5] has another link in the middle of a paragraph that points to "formatted string literals", that eventually brings us to the right page[6]; 6) the "right page"[6] has a wall of text with a block of code containing the grammar, luckily followed by a few examples. I think we should: 1) add index entries for "f-string" and "fstring" in the relevant sections of the docs, so that they appear in the search result; 2) in the Text Sequence Type — str[3] section, have a bullet list for f-strings, raw-strings, and possibly u-strings; 3) possibly use the term "f-string" in addition (or instead) of "formatted string literal", to make the pages more ctrl+f-friendly throughout the docs; 4) possibly have another more newbie-friendly section on f-string (compared to the lexical analysis page) in the tutorial, in the stdtypes page[7] (e.g. before the printf-style String Formatting" section[8]), or in the string page[2] (e.g. after the "Format String Syntax" section[10]); 5) possibly reorganize and consolidate the different sections about strings, string methods, str.format(), the format mini-language, f-strings, raw/unicode-strings, %-style formatting in a single page or two (a page for the docs and one for the grammar), since it seems to me that over the years these sections got a bit scattered around as they were being added. [0]: https://docs.python.org/3/search.html?q=fstring [1]: https://docs.python.org/3/search.html?q=f-string [2]: https://docs.python.org/3/library/string.html [3]: https://docs.python.org/3/library/stdtypes.html#textseq [4]: https://docs.python.org/3/library/stdtypes.html#string-methods [5]: https://docs.python.org/3/library/string.html#formatstrings [6]: https://docs.python.org/3/reference/lexical_analysis.html#f-strings [7]: https://docs.python.org/3/library/stdtypes.html [8]: https://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting -- assignee: docs@python components: Documentation messages: 374398 nosy: docs@python, eric.smith, ezio.melotti priority: normal severity: normal stage: needs patch status: open title: Improve and consolidate f-strings docs type: enhancement versions: Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41411> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41045] f-string's "debug" feature is undocumented
Ezio Melotti added the comment: I was just just trying to link to someone the documentation for f-strings, but: 1) Searching "fstring" only returns two results about xdrlib[0]; 2) Searching "f-string" returns many unrelated results[1]; 3) The first (and closer) result (string -- Common string operations[2]) yields nothing while using ctrl+f with fstring, f-string, f', f"; 4) at the top of that page there are two links in a "see also": * Text Sequence Type — str[3]: it mentions raw strings at the beginning, but also yields no results for fstring, f-string, f', f"; * String Methods[4]: that is another section of the previous page (so ctrl+f doesn't find anything), but has a link to "Format String Syntax"[5]; 5) The "Format String Syntax" page[5] has another link in the middle of a paragraph that points to "formatted string literals", that eventually brings us to the right page[6]; 6) the "right page"[6] has a wall of text with a block of code containing the grammar, luckily followed by a few examples. I think we should: 1) add index entries for "f-string" and "fstring" in the relevant sections of the docs, so that they appear in the search result; 2) in the Text Sequence Type — str[3] section, have a bullet list for f-strings, raw-strings, and possibly u-strings; 3) possibly use the term "f-string" in addition (or instead) of "formatted string literal", to make the pages more ctrl+f-friendly throughout the docs; 4) possibly have another more newbie-friendly section on f-string (compared to the lexical analysis page) in the tutorial, in the stdtypes page[7] (e.g. before the printf-style String Formatting" section[8]), or in the string page[2] (e.g. after the "Format String Syntax" section[10]); 5) possibly reorganize and consolidate the different sections about strings, string methods, str.format(), the format mini-language, f-strings, raw/unicode-strings, %-style formatting in a single page or two (a page for the docs and one for the grammar), since it seems to me that over the years these sections got a bit scattered around as they were being added. If you think this is out of the scope of this issue, I can open a separate one. [0]: https://docs.python.org/3/search.html?q=fstring [1]: https://docs.python.org/3/search.html?q=f-string [2]: https://docs.python.org/3/library/string.html [3]: https://docs.python.org/3/library/stdtypes.html#textseq [4]: https://docs.python.org/3/library/stdtypes.html#string-methods [5]: https://docs.python.org/3/library/string.html#formatstrings [6]: https://docs.python.org/3/reference/lexical_analysis.html#f-strings [7]: https://docs.python.org/3/library/stdtypes.html [8]: https://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting -- nosy: +ezio.melotti type: -> enhancement ___ Python tracker <https://bugs.python.org/issue41045> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41080] re.sub treats * incorrectly?
Ezio Melotti added the comment:
This behavior was changed in 3.7: "Empty matches for the pattern are replaced
only when not adjacent to a previous empty match, so sub('x*', '-', 'abxd')
returns '-a-b--d-'." [0]
See also bpo-32308 and bpo-25054.
[0]: https://docs.python.org/3/library/re.html#re.sub
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
superseder: -> Replace empty matches adjacent to a previous non-empty match in
re.sub()
___
Python tracker
<https://bugs.python.org/issue41080>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40873] Something wrong with html.unescape()
Change by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker <https://bugs.python.org/issue40873> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40799] Create Lib/_pydecimal.py file to optimize "import datetime" when _decimal is available
Change by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker <https://bugs.python.org/issue40799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40711] Clearing the screen of IDLE interactive mode in Windows
Ezio Melotti added the comment: The cls command only works when Python is executed within a Windows terminal. In other contexts (such as IDLE), the command doesn't work. -- assignee: terry.reedy -> ezio.melotti nosy: +ezio.melotti resolution: -> not a bug stage: -> resolved status: open -> closed type: performance -> behavior ___ Python tracker <https://bugs.python.org/issue40711> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40710] Malfunctioning of '\r' (ii)
Ezio Melotti added the comment: Correct. This is a Windows issue, not a Python one. -- resolution: -> not a bug status: open -> closed ___ Python tracker <https://bugs.python.org/issue40710> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40708] Clearing the screen of IDLE interactive mode in Windows
Change by Ezio Melotti : -- assignee: terry.reedy -> ezio.melotti nosy: +ezio.melotti resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Clearing the screen of IDLE interactive mode in Windows type: performance -> behavior ___ Python tracker <https://bugs.python.org/issue40708> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40710] Malfunctioning of '\r'
Ezio Melotti added the comment: The behavior of \r depends on the operating system and terminal you are using, and not on Python itself. -- assignee: terry.reedy -> ezio.melotti nosy: +ezio.melotti resolution: -> not a bug stage: -> resolved status: open -> closed type: performance -> behavior ___ Python tracker <https://bugs.python.org/issue40710> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40709] Malfunctioning of '\r'
Ezio Melotti added the comment: The behavior of \r depends on the operating system and terminal you are using, and not on Python itself. -- assignee: terry.reedy -> ezio.melotti nosy: +ezio.melotti resolution: -> not a bug stage: -> resolved status: open -> closed type: performance -> behavior ___ Python tracker <https://bugs.python.org/issue40709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39833] Bug in html parsing module triggered by malformed input
Ezio Melotti added the comment: Thanks for the report. This is a duplicate of #34480. -- nosy: +ezio.melotti resolution: -> duplicate stage: -> resolved status: open -> closed type: compile error -> behavior ___ Python tracker <https://bugs.python.org/issue39833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39279] Don't allow non-Ascii digits in platform.py
Ezio Melotti added the comment: Do you know/can you verify if Chinese versions of Windows/Linux/MacOS include non-ASCII version numbers (e.g. fullwidth digits)? -- ___ Python tracker <https://bugs.python.org/issue39279> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39368] A matrix (list of lists) behaves differently, depending how it is created
Ezio Melotti added the comment: See also https://docs.python.org/3/faq/programming.html#why-did-changing-list-y-also-change-list-x You can use the builtin function id() to see the id of the lists, and verify whether they refer to the same object or not. -- nosy: +ezio.melotti resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue39368> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39279] Don't allow non-Ascii digits in platform.py
Ezio Melotti added the comment: Can you elaborate on the rational for this proposed change? I'm not sure if there cases where the digits are non-ASCII, but if there are, is rejecting them the right thing to do? In the code there's a comment that mentions that the Windows version can be localized, so if the version number uses non-ASCII digits and we change the regex to only accept [0-9], those version strings won't be accepted/recognized anymore. -- nosy: +ezio.melotti ___ Python tracker <https://bugs.python.org/issue39279> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34480] _markupbase.py fails with UnboundLocalError on invalid keyword in marked section
Ezio Melotti added the comment: I think so. It might be worth double-checking if BeautifulSoup (and possibly other 3rd party libs) use _markupbase.py and/or ParserBase.error(). If they do, giving them a heads up and/or going through a regular deprecation process might be good, otherwise PR 8562 can be reopened and merged after removing the call to self.error() in ParserBase.parse_marked_section(). -- ___ Python tracker <https://bugs.python.org/issue34480> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34979] Python throws “SyntaxError: Non-UTF-8 code start with \xe8...” when parse source file
Change by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker <https://bugs.python.org/issue34979> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38201] Anotation problem at flask_httpauth package
Ezio Melotti added the comment: Please read the documentation for login_required at https://flask-login.readthedocs.io/en/latest/#flask_login.login_required and if you still think you have found a bug report it to the Flask bug tracker. -- nosy: +ezio.melotti resolution: -> not a bug stage: -> resolved status: open -> closed type: -> behavior ___ Python tracker <https://bugs.python.org/issue38201> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2771] Test issue
Ezio Melotti added the comment: test comment -- ___ Python tracker <https://bugs.python.org/issue2771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38103] Duplicate label "examples" in the Docs
Change by Ezio Melotti : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue38103> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38103] Duplicate label "examples" in the Docs
Change by Ezio Melotti : -- keywords: +patch pull_requests: +15547 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15906 ___ Python tracker <https://bugs.python.org/issue38103> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38103] Duplicate label "examples" in the Docs
New submission from Ezio Melotti : I just rebuilt the docs and got the following error: Warning, treated as error: Doc/c-api/typeobj.rst:2456:duplicate label examples, other instance in Doc/distutils/examples.rst Makefile:49: recipe for target 'build' failed make: *** [build] Error 2 -- assignee: ezio.melotti components: Documentation messages: 351789 nosy: ezio.melotti priority: normal severity: normal stage: needs patch status: open title: Duplicate label "examples" in the Docs type: behavior versions: Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue38103> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37584] Multiple test failures with OSError: [Errno 84] Invalid or incomplete multibyte or wide character on ZFS with utf8only=on
Ezio Melotti added the comment:
I think Dimiter was able to fix most of the failures, except
test_unicode_file_functions.
Yesterday during the sprints we were looking at it, and we did some tests using
the following snippet:
import os
import unicodedata
upsilon_diaeresis_and_hook = "ϔ"
for form in ["NFC", "NFD", "NFKC", "NFKD"]:
unicode_filename = unicodedata.normalize(form, upsilon_diaeresis_and_hook)
with open(unicode_filename, "w") as f: f.write(form)
print("N:", ascii(unicode_filename))
print([ascii(filename) for filename in os.listdir('.')])
On ext4 this creates 4 different files: ['\u03d4', '\u03d2\u0308', '\u03ab',
'\u03a5\u0308']
On ZFS with utf8only=true (and I believe normalization=formD), only 2 files are
created but each of the 4 filenames can be used to access either of the 2 files.
This is also the default behavior on Mac.
The test is already skipped on darwin
(Lib/test/test_unicode_file_functions.py:120), and should be skipped for ZFS
too (might depend on the exact flags used), however we weren't able to find a
portable way to determine the filesystem and flags.
An alternative is to try creating the 4 files and skip the test if only 2 gets
created and if all the names can be used to open these two files, however this
might mask other failures. Unless someone can come up with a better way to do
this, I think this is the only option.
In addition, different filesystems that don't exhibit this behavior can be used
on Mac, so the test shouldn't be skipped in those cases.
--
nosy: +serhiy.storchaka
stage: -> test needed
___
Python tracker
<https://bugs.python.org/issue37584>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7940] re.finditer and re.findall should support negative end positions
Ezio Melotti added the comment:
> Are there any real world examples which show the benefit of supporting
> negative indices?
A common case is ignoring parentheses at the beginning/end, e.g.
>>> re.compile('[^,]+').findall('(foo,123,(),bar)')
['(foo', '123', '()', 'bar)']
>>> # ignore the surrounding ()
>>> re.compile('[^,]+').findall('(foo,123,(),bar)', 1, 15)
['foo', '123', '()', 'bar']
>>>
>>> # extract attributes from a tag (poc, doesn't handle all cases)
>>> re.compile('[^ ]+').findall('', 7,
>>> 39)
['type="checkbox"', 'id="foo"', 'checked']
In both cases using -1 as endpos is simpler.
--
versions: +Python 3.9 -Python 3.5
___
Python tracker
<https://bugs.python.org/issue7940>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7940] re.finditer and re.findall should support negative end positions
Ezio Melotti added the comment:
Sorry, I was wrong. re.findall accepts negative indices for both start and end
but they silently get converted to 0, which is arguably an unexpected behavior.
This is an example of the current behavior:
>>> s, e = 1, 4; re.compile('.').findall('abcde', s, e), 'abcde'[s:e]
(['b', 'c', 'd'], 'bcd')
>>> s, e = -4, 4; re.compile('.').findall('abcde', s, e), 'abcde'[s:e]
(['a', 'b', 'c', 'd'], 'bcd')
>>> s, e = 1, -1; re.compile('.').findall('abcde', s, e), 'abcde'[s:e]
([], 'bcd')
>>> s, e = -4, -1; re.compile('.').findall('abcde', s, e), 'abcde'[s:e]
([], 'bcd')
With the patch, all these return ['b', 'c', 'd']. This change might indeed
cause issues because it's a change in behavior, but I'm also not sure there are
many cases where one would want a negative index to be treated as 0. Maybe we
could raise a FutureWarning in the next release and change the behavior
afterwards?
--
___
Python tracker
<https://bugs.python.org/issue7940>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7940] re.finditer and re.findall should support negative end positions
Ezio Melotti added the comment: The current behavior is inconsistent because the start position accepts both positive and negative indices, whereas the end position only accepts positive indices. I think the proposal and the PR written by Anil are reasonable and should be merged. -- ___ Python tracker <https://bugs.python.org/issue7940> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37328] remove deprecated HTMLParser.unescape
Change by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker <https://bugs.python.org/issue37328> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15474] Differentiate decorator and decorator factory in docs
Ezio Melotti added the comment: If you want some early feedback I believe you can already create a PR and mark it as work-in-progress/don't-merge. If you need some material you can find the slides of a talk about decorators that I did at https://www.pycon.it/media/conference/slides/understanding-decorators.pdf Feel free to take from it whatever you need :) -- versions: +Python 3.7, Python 3.8, Python 3.9 -Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <https://bugs.python.org/issue15474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21492] email.header.decode_header sometimes returns bytes, sometimes str
Ezio Melotti added the comment:
If we can't fix the behavior, it should at least be documented.
Currently the docs says "This function returns a list of (decoded_string,
charset) pairs containing each of the decoded parts of the header.". One could
assume that this means that a Unicode string is returned, but and as far as I
can tell, "decoded_string" means decoded from the format used by the header,
not from bytes -- in fact the example below shows a byte string.
#24797 suggest an alternative solution, but there is no indications about it in
the docs except an easy-to-miss note about the new API at the top.
Coincidentally as I was reporting this issue I also found the recently opened
#37139. There are also a few other reports: #24797, #37139, #32975, #6302,
#4661.
If this method is not actually deprecated, I would document the current
behavior (i.e. sometimes it returns bytes, sometimes unicode -- bonus points if
there's a simple rule to predict which one), explain that it exists for
legacy/backward-compatibility reasons, and point to the alternatives.
FWIW here are 3 more samples that show the inconsistency.
>>> from email.header import decode_header
>>> # str + None
>>> h = '\x80SOKCrGxsbw= '; decode_header(h)
[('\x80SOKCrGxsbw= ', None)]
>>> # bytes + '', bytes + None
>>> h = '=??b?SOKCrGxsbw=?= '; decode_header(h)
[(b'H\xe2\x82\xacllo', ''), (b' ', None)]
>>> # bytes + 'utf8', bytes + None
>>> h = '=?utf8?b?SOKCrGxsbw==?= '; decode_header(h)
[(b'H\xe2\x82\xacllo', 'utf8'), (b' ', None)]
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python, ezio.melotti, louis.abra...@yahoo.fr
resolution: duplicate ->
stage: resolved -> needs patch
status: closed -> open
type: behavior -> enhancement
___
Python tracker
<https://bugs.python.org/issue21492>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19184] dis module has incorrect docs for RAISE_VARARGS
Ezio Melotti added the comment: Fixed, thanks for the report and the PRs! -- assignee: docs@python -> ezio.melotti resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> enhancement versions: +Python 3.7 ___ Python tracker <https://bugs.python.org/issue19184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19184] dis module has incorrect docs for RAISE_VARARGS
Ezio Melotti added the comment: New changeset 9390e98c3ed9eb9fa414030a2feec1926193af94 by Ezio Melotti (Miss Islington (bot)) in branch '3.7': bpo-19184: Update the documentation of dis module. (GH-13652) (GH-13755) https://github.com/python/cpython/commit/9390e98c3ed9eb9fa414030a2feec1926193af94 -- ___ Python tracker <https://bugs.python.org/issue19184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37014] fileinput module should document that openhook and mode are ignored when reading from stdin
Ezio Melotti added the comment: Fixed, thanks for the report and the PRs! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed title: [First easy issue] fileinput module should document that openhook and mode are ignored when reading from stdin -> fileinput module should document that openhook and mode are ignored when reading from stdin type: -> enhancement versions: +Python 3.8 ___ Python tracker <https://bugs.python.org/issue37014> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37014] [First easy issue] fileinput module should document that openhook and mode are ignored when reading from stdin
Ezio Melotti added the comment: New changeset 6bd438e137a0618b8db949a4751304f541b6674d by Ezio Melotti (Miss Islington (bot)) in branch '3.7': bpo-37014: Update docstring and Documentation of fileinput.FileInput(). (GH-13545) (GH-13753) https://github.com/python/cpython/commit/6bd438e137a0618b8db949a4751304f541b6674d -- ___ Python tracker <https://bugs.python.org/issue37014> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19184] dis module has incorrect docs for RAISE_VARARGS
Ezio Melotti added the comment: New changeset e1179a5096fb12297ececd7a1c79969aa5747e28 by Ezio Melotti (Michele Angrisano) in branch 'master': bpo-19184: Update the documentation of dis module. (GH-13652) https://github.com/python/cpython/commit/e1179a5096fb12297ececd7a1c79969aa5747e28 -- nosy: +ezio.melotti ___ Python tracker <https://bugs.python.org/issue19184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37014] [First easy issue] fileinput module should document that openhook and mode are ignored when reading from stdin
Ezio Melotti added the comment: New changeset aca273e2401ca3151e15e984f400233b7f255e15 by Ezio Melotti (Michele Angrisano) in branch 'master': bpo-37014: Update docstring and Documentation of fileinput.FileInput(). (GH-13545) https://github.com/python/cpython/commit/aca273e2401ca3151e15e984f400233b7f255e15 -- nosy: +ezio.melotti ___ Python tracker <https://bugs.python.org/issue37014> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2771] Test issue
Change by Ezio Melotti : ___ Python tracker <https://bugs.python.org/issue2771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2771] Test issue
Change by Ezio Melotti : -- components: +Tests keywords: +easy (C) priority: -> low versions: +Python 3.9 -Python 3.8 ___ Python tracker <https://bugs.python.org/issue2771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36713] duplicate method definition in Lib/ctypes/test/test_unicode.py
Ezio Melotti added the comment: Fixed, thanks for the PR! -- assignee: -> ezio.melotti resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36713> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36713] duplicate method definition in Lib/ctypes/test/test_unicode.py
Ezio Melotti added the comment: New changeset 25d8404c358f3b1cc8321cdc74049d45dcb8d014 by Ezio Melotti (Michele Angrisano) in branch '2.7': bpo-36713: Rename duplicated method in test_unicode. (#13525) https://github.com/python/cpython/commit/25d8404c358f3b1cc8321cdc74049d45dcb8d014 -- ___ Python tracker <https://bugs.python.org/issue36713> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36713] duplicate method definition in Lib/ctypes/test/test_unicode.py
Ezio Melotti added the comment: The duplicate method is gone from 3.5+, but it is still present on 2.7: 2.7/Lib/ctypes/test/test_unicode.py:96 2.7/Lib/ctypes/test/test_unicode.py:110 The one at line 96 should be renamed "test_ascii_strict". Michele, do you want to work on a PR to fix it? -- nosy: +ezio.melotti ___ Python tracker <https://bugs.python.org/issue36713> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36892] "Modules" section in Tutorial contains incorrect description about __init__.py
Ezio Melotti added the comment: I agree that implicit namespace packages don't deserve more than a footnote in that page. However, since I often have to answer questions about packages, I'm thinking that perhaps it would be better to expand that page and maybe have a page dedicated to modules and one to packages, where PEP 420 and other common issues could be covered in more details. -- nosy: +ezio.melotti ___ Python tracker <https://bugs.python.org/issue36892> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36789] Unicode HOWTO incorrectly states that UTF-8 contains no zero bytes
Change by Ezio Melotti : -- nosy: +ezio.melotti type: -> enhancement ___ Python tracker <https://bugs.python.org/issue36789> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36425] Add Simplified Chinese to the language switcher
Change by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker <https://bugs.python.org/issue36425> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36139] release GIL on mmap dealloc
Ezio Melotti added the comment: > Oh wow, that's really strange. I'm sure that I wrote "https://..."; URL but my > URL became "r263026496">https://..."; !? The links are now fixed (Roundup was getting confused by the rNN, since it looks like a SVN revision). -- nosy: +ezio.melotti type: -> performance ___ Python tracker <https://bugs.python.org/issue36139> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2771] Test issue
Ezio Melotti added the comment: test message via email -- ___ Python tracker <https://bugs.python.org/issue2771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35354] Generator functions stack overflow
Change by Ezio Melotti : -- nosy: -asdwqii ___ Python tracker <https://bugs.python.org/issue35354> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35354] Generator functions stack overflow
Ezio Melotti added the comment: > I think I have seen this bug reported elsewhere but can't find it now. Sorry, I was referring to issue6028 and issue32570 that I thought were similar to the original report. (Karthikeyan is having trouble posting, so I'm trying on his behalf.) -- nosy: +ezio.melotti ___ Python tracker <https://bugs.python.org/issue35354> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25416] Add encoding aliases from the (HTML5) Encoding Standard
Ezio Melotti added the comment: Adding those aliases sounds good to me. I think it would be good to add some tests first (possibly as a separate issue/pr), even though I'm not sure what would be the best way to test the aliases. Testing if the list is complete/correct should be done against the HTML5/Unicode specs, but that, if automated, would require downloading/parsing the specs and is probably not worth doing it. We can also check that all the aliases are accepted by str.encode/decode, and all corresponding aliases should give the same result, however if str.encode/decode use the aliases dict, the test is nothing more than a sanity check and won't detect e.g. typos in the aliases names, or wrongly assigned aliases. -- nosy: +fbidu stage: patch review -> test needed versions: +Python 3.8 -Python 3.6 ___ Python tracker <https://bugs.python.org/issue25416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35072] re.sub does not play nice with chr(92)
Ezio Melotti added the comment:
I'm assuming you want to replace double backslashes with single backslashes in
stringy_thing, so I defined stringy_thingy and tried both your snippets but
they are both failing:
>>> stringy_thingy = r'foo\\bar\\baz'
>>> print(stringy_thingy) # stringy_thingy contains double backslashes
foo\\bar\\baz
>>> re.sub(r'', chr(92), stringy_thingy) # fails
Traceback (most recent call last):
...
File "/usr/lib/python3.6/sre_parse.py", line 245, in __next
self.string, len(self.string) - 1) from None
sre_constants.error: bad escape (end of pattern) at position 0
>>>
>>> parser = re.compile(r'')
>>> parser.sub(chr(92), stringy_thingy) # also fails
Traceback (most recent call last):
...
File "/usr/lib/python3.6/sre_parse.py", line 245, in __next
self.string, len(self.string) - 1) from None
sre_constants.error: bad escape (end of pattern) at position 0
Replacing chr(92) with r'\\' works for both:
>>> print(re.sub(r'', r'\\', stringy_thingy))
foo\bar\baz
>>> print(parser.sub(r'\\', stringy_thingy))
foo\bar\baz
The docs[0] says: "repl can be a string or a function; if it is a string, any
backslash escapes in it are processed."
So passing chr(92) (or '\\', which is equivalent) result in the above error
("bad escape (end of pattern)") because it's seen as an incomplete escape
sequence. Passing r'\\' seems to work as intended.
ISTM there is no bug and re.sub works as documented. Can you provide a
stringy_thingy for which the first of your snippet fails but the second
succeeds?
[0]: https://docs.python.org/3/library/re.html#re.sub
--
resolution: -> not a bug
stage: -> test needed
status: open -> pending
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue35072>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34935] Misleading error message in str.decode()
Change by Ezio Melotti : -- assignee: -> ezio.melotti resolution: -> not a bug stage: -> resolved status: open -> closed type: -> behavior ___ Python tracker <https://bugs.python.org/issue34935> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2771] Test issue
Ezio Melotti added the comment: mail test -- ___ Python tracker <https://bugs.python.org/issue2771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34917] add time decorator to timeit.py
Ezio Melotti added the comment: Thanks for the decorator, however this should probably be discussed on python-ideas first to decide if a decorator should be added in the first place. If the idea is accepted, the exact implementation should be discussed and defined, and finally a pull request should be submitted. The decorator you submitted can't be accepted as it is, so for the time being, I'm going to reject it and close the issue. -- nosy: +ezio.melotti resolution: -> rejected stage: -> resolved status: open -> closed versions: +Python 3.8 -Python 3.7 ___ Python tracker <https://bugs.python.org/issue34917> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2771] Test issue
Ezio Melotti added the comment: another test -- ___ Python tracker <https://bugs.python.org/issue2771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31865] html.unescape does not work as per documentation
Ezio Melotti added the comment: Fixed, thanks for the report! -- keywords: -patch resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue31865> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31865] html.unescape does not work as per documentation
Ezio Melotti added the comment: New changeset 56c102596f01ecbbe5cca6339d2ae16695b083ff by Ezio Melotti (Miss Islington (bot)) in branch '3.6': bpo-31865: Fix a couple of typos in the html.unescape() docs. (GH-9664) https://github.com/python/cpython/commit/56c102596f01ecbbe5cca6339d2ae16695b083ff -- ___ Python tracker <https://bugs.python.org/issue31865> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31865] html.unescape does not work as per documentation
Ezio Melotti added the comment: New changeset 27d7f93f633f0163b96d0a95e312f0eb5615abfd by Ezio Melotti (Miss Islington (bot)) in branch '3.7': bpo-31865: Fix a couple of typos in the html.unescape() docs. (GH-9663) https://github.com/python/cpython/commit/27d7f93f633f0163b96d0a95e312f0eb5615abfd -- ___ Python tracker <https://bugs.python.org/issue31865> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31865] html.unescape does not work as per documentation
Ezio Melotti added the comment: New changeset 30534cc7172f36092e0002bb7df482edc0d539ce by Ezio Melotti in branch 'master': bpo-31865: Fix a couple of typos in the html.unescape() docs. (GH-9662) https://github.com/python/cpython/commit/30534cc7172f36092e0002bb7df482edc0d539ce -- ___ Python tracker <https://bugs.python.org/issue31865> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31865] html.unescape does not work as per documentation
Change by Ezio Melotti : -- keywords: +patch pull_requests: +9055 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue31865> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31865] html.unescape does not work as per documentation
Change by Ezio Melotti : -- assignee: docs@python -> ezio.melotti keywords: +easy stage: -> needs patch ___ Python tracker <https://bugs.python.org/issue31865> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32956] python 3 round bug
Change by Ezio Melotti : -- nosy: +ezio.melotti, mark.dickinson ___ Python tracker <https://bugs.python.org/issue32956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34792] Tutorial doesn''t discuss / and * function arguments
Change by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker <https://bugs.python.org/issue34792> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2771] Test issue
Ezio Melotti added the comment: test -- nosy: +nedbat ___ Python tracker <https://bugs.python.org/issue2771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2771] Test issue
Ezio Melotti added the comment: test -- nosy: -nedbat ___ Python tracker <https://bugs.python.org/issue2771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32876] HTMLParser raises exception on some inputs
Change by Ezio Melotti : -- keywords: +patch pull_requests: +8724 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue32876> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34480] _markupbase.py fails with UnboundLocalError on invalid keyword in marked section
Change by Ezio Melotti : -- assignee: -> ezio.melotti ___ Python tracker <https://bugs.python.org/issue34480> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31844] HTMLParser: undocumented not implemented method
Change by Ezio Melotti : -- assignee: -> ezio.melotti ___ Python tracker <https://bugs.python.org/issue31844> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34087] int(s), float(s) and others may cause segmentation fault
Change by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker <https://bugs.python.org/issue34087> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32876] HTMLParser raises exception on some inputs
Change by Ezio Melotti : -- assignee: -> ezio.melotti ___ Python tracker <https://bugs.python.org/issue32876> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32876] HTMLParser raises exception on some inputs
Ezio Melotti added the comment: The HTMLParser has been updated to handle HTML5 and should never fail parsing a document, so if it raises an error it's probably a bug. -- ___ Python tracker <https://bugs.python.org/issue32876> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2771] Test issue
Change by Ezio Melotti : -- Removed message: https://bugs.python.org/msg303087 ___ Python tracker <https://bugs.python.org/issue2771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31714] Improve re documentation
Ezio Melotti added the comment: ISTM that ``x`` is used when x is a regex or regex metachar, whereas ``'x'`` is used when 'x' is a string. I find this distinction reasonable. -- ___ Python tracker <https://bugs.python.org/issue31714> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31589] Links for French documentation pdf is broken
Ezio Melotti added the comment: FWIW most of the errors I met while trying to build the pdfs of the main docs were caused by the presence of non-latin1 characters. French should be limited to the latin1 range and the error you pasted doesn't seem to be related, however that might explain while the Japanese docs are also missing (unless this issue got fixed in the meanwhile -- I haven't built the pdfs in a while). -- nosy: +ezio.melotti type: -> behavior ___ Python tracker <https://bugs.python.org/issue31589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31605] meta issue: bugs.python.org search shows only issues with recent activity
Ezio Melotti added the comment: This should be fixed now, thanks for the report! -- assignee: -> ezio.melotti resolution: -> third party stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue31605> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2771] Test issue
Ezio Melotti added the comment: mail test On Wed, Sep 27, 2017 at 4:14 AM, Ezio Melotti wrote: > > Ezio Melotti added the comment: > > test > > -- > versions: +Python 3.8 -Python 3.5 > > ___ > Python tracker > <https://bugs.python.org/issue2771> > ___ > -- ___ Python tracker <https://bugs.python.org/issue2771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2771] Test issue
Ezio Melotti added the comment: test -- versions: +Python 3.8 -Python 3.5 ___ Python tracker <https://bugs.python.org/issue2771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31580] Defer compiling regular expressions
Ezio Melotti added the comment: What about adding a lazy_compile() function? It will leave the current behavior unchanged, it's explicit, and it's easier to use cross version (if importing re.lazy_compile fails, use re.compile). FWIW I'm -1 on changing re.compile, -1 on adding re.IMMEDIATE, -0.5 on adding re.DEFERRED (not sure this option belongs among the re flag), +1 on adding a compile-time optimization. -- nosy: +ezio.melotti ___ Python tracker <https://bugs.python.org/issue31580> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31553] Extend json.tool to handle jsonlines (with a flag)
Ezio Melotti added the comment: I agree with Raymond that this is a reasonable request. Even if jsonlines is not part of the JSON specification, the format is quite common, and practicality beats purity (espcially considering that we are just talking about json.tool). -- nosy: +ezio.melotti ___ Python tracker <https://bugs.python.org/issue31553> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31484] Cache single-character strings outside of the Latin1 range
Ezio Melotti added the comment: > The cache of size 2 x 256 slots can increase memory consumption by 50 KiB in > worst case, 2 x 1024 -- by 200 KiB. How much is this compared to the total usage? > But I don't know how common `for c in s` or `s[i]` is used for Japanese text. I think the same applies to other languages/scripts too, so this optimization might be moot unless the cache also improves performances of other more common operations (e.g. encoding/decoding). It would be interesting to see how this affects real-world application: if there are no regressions and the memory overhead is not too much I think we can accept the patch. -- ___ Python tracker <https://bugs.python.org/issue31484> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31484] Cache single-character strings outside of the Latin1 range
Ezio Melotti added the comment: The Greek sample includes 155 unique characters (including whitespace, punctuation, and the english characters at the beginning), so they can all fit in the cache. The Chinese sample however includes 3695 unique characters (all within the BMP), probably causing a lot more misses in the cache and a slowdown caused by the overhead. The Chinese text you used for the test is also from some 700 years ago, and uses traditional and vernacular Chinese, so the number of unique character is higher than what you would normally encounter in modern Chinese. -- ___ Python tracker <https://bugs.python.org/issue31484> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
