[issue27886] Docs: the difference between rename and replace is not obvious

2020-10-28 Thread Ezio Melotti


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

2020-10-12 Thread Ezio Melotti


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

2020-09-09 Thread Ezio Melotti


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

2020-07-30 Thread Ezio Melotti


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 they are;
* update the in

[issue41411] Improve and consolidate f-strings docs

2020-07-28 Thread Ezio Melotti

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

2020-07-27 Thread Ezio Melotti


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

2020-07-27 Thread Ezio Melotti


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

2020-07-27 Thread Ezio Melotti

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

2020-07-27 Thread Ezio Melotti

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?

2020-06-22 Thread Ezio Melotti


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()

2020-06-19 Thread Ezio Melotti


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

2020-05-27 Thread Ezio Melotti


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

2020-05-21 Thread Ezio Melotti


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)

2020-05-21 Thread Ezio Melotti


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

2020-05-21 Thread Ezio Melotti


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'

2020-05-21 Thread Ezio Melotti


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'

2020-05-21 Thread Ezio Melotti


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

2020-03-02 Thread Ezio Melotti


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

2020-01-22 Thread Ezio Melotti


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

2020-01-17 Thread Ezio Melotti


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

2020-01-10 Thread Ezio Melotti


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

2020-01-06 Thread Ezio Melotti


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



[issue34480] _markupbase.py fails with UnboundLocalError on invalid keyword in marked section

2020-01-05 Thread Ezio Melotti
<pre>

Ezio Melotti <ezio.melo...@gmail.com> added the comment:

HTMLParser is supposed to follow the HTML5 standard, and never raise an error.

For the example in the first comment ("<![hi world]>"), the steps should be:

* <a  rel="nofollow" href="https://html.spec.whatwg.org/multipage/parsing.html#data-state:tag-open-state">https://html.spec.whatwg.org/multipage/parsing.html#data-state:tag-open-state</a>
* 
<a  rel="nofollow" href="https://html.spec.whatwg.org/multipage/parsing.html#tag-open-state:markup-declaration-open-state">https://html.spec.whatwg.org/multipage/parsing.html#tag-open-state:markup-declaration-open-state</a>
* 
<a  rel="nofollow" href="https://html.spec.whatwg.org/multipage/parsing.html#markup-declaration-open-state:bogus-comment-state">https://html.spec.whatwg.org/multipage/parsing.html#markup-declaration-open-state:bogus-comment-state</a>
* <a  rel="nofollow" href="https://html.spec.whatwg.org/multipage/parsing.html#bogus-comment-state">https://html.spec.whatwg.org/multipage/parsing.html#bogus-comment-state</a>

I agree that the error should be fixed by setting `match` to None, and a test 
case that triggers the UnboundLocalError (before the fix) should be added as 
well (what provided by Karthikeyan looks good).

However, it also seems wrong that HTMLParser ends up calling self.error() 
through  Lib/_markupbase.py ParserBase after HTMLParser.error() and all the 
calls to it have been removed.  _markupbase.py is internal, so it should be 
safe to remove ParserBase.error() and the code that calls it as suggested in 
#31844 (and possibly to merge _markupbase into html.parser too).  Even if this 
is done and the call to self.error() is removed from 
ParserBase.parse_marked_section(), `match` still needs to be set to None 
(either in the `else` branch or before the `if/elif` block).

--

___
Python tracker <rep...@bugs.python.org>
<<a  rel="nofollow" href="https://bugs.python.org/issue34480">https://bugs.python.org/issue34480</a>>
___
___
Python-bugs-list mailing list
Unsubscribe: 
<a  rel="nofollow" href="https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com">https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com</a>

</pre>

[issue34979] Python throws “SyntaxError: Non-UTF-8 code start with \xe8...” when parse source file

2019-11-15 Thread Ezio Melotti


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

2019-09-17 Thread Ezio Melotti


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

2019-09-11 Thread Ezio Melotti


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

2019-09-11 Thread Ezio Melotti


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

2019-09-11 Thread Ezio Melotti


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

2019-09-11 Thread Ezio Melotti


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

2019-07-15 Thread Ezio Melotti

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

2019-07-15 Thread Ezio Melotti


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

2019-07-14 Thread Ezio Melotti


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

2019-07-14 Thread Ezio Melotti


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

2019-06-20 Thread Ezio Melotti


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

2019-06-04 Thread Ezio Melotti


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

2019-06-03 Thread Ezio Melotti


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

2019-06-02 Thread Ezio Melotti


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

2019-06-02 Thread Ezio Melotti


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

2019-06-02 Thread Ezio Melotti


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

2019-06-02 Thread Ezio Melotti


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

2019-06-02 Thread Ezio Melotti


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

2019-06-02 Thread Ezio Melotti


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

2019-05-24 Thread Ezio Melotti


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

2019-05-24 Thread Ezio Melotti


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

2019-05-23 Thread Ezio Melotti


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

2019-05-23 Thread Ezio Melotti


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

2019-05-23 Thread Ezio Melotti


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

2019-05-11 Thread Ezio Melotti


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

2019-05-05 Thread Ezio Melotti


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

2019-03-28 Thread Ezio Melotti


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

2019-03-06 Thread Ezio Melotti


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

2018-12-22 Thread Ezio Melotti


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

2018-11-29 Thread Ezio Melotti


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

2018-11-29 Thread Ezio Melotti


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

2018-10-31 Thread Ezio Melotti


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)

2018-10-25 Thread Ezio Melotti


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()

2018-10-10 Thread Ezio Melotti


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

2018-10-09 Thread Ezio Melotti


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

2018-10-06 Thread Ezio Melotti


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

2018-10-02 Thread Ezio Melotti


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

2018-10-01 Thread Ezio Melotti


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

2018-10-01 Thread Ezio Melotti


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

2018-10-01 Thread Ezio Melotti


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

2018-10-01 Thread Ezio Melotti


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

2018-10-01 Thread Ezio Melotti


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

2018-10-01 Thread Ezio Melotti


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

2018-09-24 Thread Ezio Melotti


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

2018-09-24 Thread Ezio Melotti


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

2018-09-23 Thread Ezio Melotti


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

2018-09-23 Thread Ezio Melotti


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

2018-09-14 Thread Ezio Melotti
<pre>

Ezio Melotti <ezio.melo...@gmail.com> added the comment:

There are at least a couple of issues here.

The first one is the way the parser handles '<![...'.  The linked page contains 
markup like '<![STAT]-[USER-ACTIVE]!>' and since the parser currently checks 
for '<![' only, _markupbase.py:parse_marked_section gets called and an error 
gets incorrectly raised.   
However "8.2.4.42. Markup declaration open state"[0], states that after 
consuming '<!', there are only 4  valid paths forward:
1) if we have '<!--', it's a comment;
2) if we have '<!doctype', it's a doctype declaration;
3) if we have '<![CDATA[', it's a CDATA section;
4) if it's something else, it's a bogus comment;

The above example should therefore fall into 4), and be treated like a bogus 
comment.

PR-9295 changes parse_html_declaration() to align to the specs and implement 
path 3), resulting in the webpage being parsed without errors (the invalid 
markup is considered as a bogus comment).


The second issue is about an EOF in the middle of a bogus markup declaration, 
like in the minified example provided by OP ("<![\n").  In this case the 
comment should still be emitted ('[\n'), but currently nothing gets emitted.  
I'll look more into it either tomorrow or later this month and update the PR 
accordingly (or perhaps I'll open a separate issue).


[0]: 
<a  rel="nofollow" href="https://www.w3.org/TR/html52/syntax.html#tokenizer-markup-declaration-open-state">https://www.w3.org/TR/html52/syntax.html#tokenizer-markup-declaration-open-state</a>

--
versions: +Python 2.7, Python 3.7, Python 3.8

___
Python tracker <rep...@bugs.python.org>
<<a  rel="nofollow" href="https://bugs.python.org/issue32876">https://bugs.python.org/issue32876</a>>
___
___
Python-bugs-list mailing list
Unsubscribe: 
<a  rel="nofollow" href="https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com">https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com</a>

</pre>

[issue32876] HTMLParser raises exception on some inputs

2018-09-14 Thread Ezio Melotti


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

2018-09-13 Thread Ezio Melotti


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

2018-08-24 Thread Ezio Melotti


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

2018-07-13 Thread Ezio Melotti


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

2018-02-25 Thread Ezio Melotti

Change by Ezio Melotti <ezio.melo...@gmail.com>:


--
assignee:  -> ezio.melotti

___
Python tracker <rep...@bugs.python.org>
<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

2018-02-19 Thread Ezio Melotti

Ezio Melotti <ezio.melo...@gmail.com> 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 <rep...@bugs.python.org>
<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

2017-10-27 Thread Ezio Melotti

Change by Ezio Melotti <ezio.melo...@gmail.com>:


--
Removed message: https://bugs.python.org/msg303087

___
Python tracker <rep...@bugs.python.org>
<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

2017-10-06 Thread Ezio Melotti

Ezio Melotti <ezio.melo...@gmail.com> 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 <rep...@bugs.python.org>
<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

2017-10-01 Thread Ezio Melotti

Ezio Melotti <ezio.melo...@gmail.com> 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 <rep...@bugs.python.org>
<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

2017-09-27 Thread Ezio Melotti

Ezio Melotti <ezio.melo...@gmail.com> 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 <rep...@bugs.python.org>
<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

2017-09-26 Thread Ezio Melotti

Ezio Melotti <ezio.melo...@gmail.com> added the comment:

mail test

On Wed, Sep 27, 2017 at 4:14 AM, Ezio Melotti <rep...@bugs.python.org>
wrote:

>
> Ezio Melotti <ezio.melo...@gmail.com> added the comment:
>
> test
>
> --
> versions: +Python 3.8 -Python 3.5
>
> ___
> Python tracker <rep...@bugs.python.org>
> <https://bugs.python.org/issue2771>
> ___
>

--

___
Python tracker <rep...@bugs.python.org>
<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

2017-09-26 Thread Ezio Melotti

Ezio Melotti <ezio.melo...@gmail.com> added the comment:

test

--
versions: +Python 3.8 -Python 3.5

___
Python tracker <rep...@bugs.python.org>
<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

2017-09-26 Thread Ezio Melotti

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 <rep...@bugs.python.org>
<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)

2017-09-23 Thread Ezio Melotti

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 <rep...@bugs.python.org>
<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

2017-09-16 Thread Ezio Melotti

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 <rep...@bugs.python.org>
<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

2017-09-15 Thread Ezio Melotti

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 <rep...@bugs.python.org>
<https://bugs.python.org/issue31484>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2771] Test issue

2017-09-07 Thread Ezio Melotti

Ezio Melotti added the comment:

test

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue2771>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue30772] If I make an attribute "[a unicode version of B]", it gets assigned to "[ascii B]", and so on.

2017-06-26 Thread Ezio Melotti

Ezio Melotti added the comment:

I can reproduce the issue:
$ cat foo.py 
픹픹 = 1
__all__ = ['픹픹']

$ python3 -c 'import foo; print(dir(foo)); from foo import *'
['BB', '__all__', '__builtins__', '__cached__', '__doc__', '__file__', 
'__loader__', '__name__', '__package__', '__spec__']
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: module 'foo' has no attribute '픹픹

(Note the ascii 'BB' in the dir(foo))


There's also an easier way to reproduce it:
>>> 픹픹= 3
>>> 픹픹
3
>>> BB
3
>>> globals()['BB']
3
>>> globals()['픹픹']
Traceback (most recent call last):
  File "", line 1, in 
KeyError: '픹픹'
>>> globals()
{'__name__': '__main__', '__spec__': None, '__builtins__': , '__loader__': , 
'__doc__': None, 'BB': 3, '__package__': None}
>>> class Foo:
... 픹  픹= 3
... 
>>> Foo.픹픹
3
>>> Foo.BB
3

It seems the '픹픹' gets normalized to 'BB' when it's an identifier, but not when 
it's a string.  I'm not sure why this happens though.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30772>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2771] Test issue

2017-06-26 Thread Ezio Melotti

Ezio Melotti added the comment:

픹픹

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue2771>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue30305] python 2.7.13 join issue

2017-05-08 Thread Ezio Melotti

Ezio Melotti added the comment:

I think you are misunderstanding how join works.
join is useful when you have a list of strings, and you want to combine them 
together, possibly specifying a separator.  The syntax is 
separator.join(list_of_strings), for example:
>>> '-'.join(['foo', 'bar', 'baz'])
'foo-bar-baz'

What you are doing is: new_item = new_item.join((item + ';'))
Here new_item is the separator, and (item + ';') is a string (a sequence of 
characters), so the separator is added between each character of the string:
>>> '-'.join('foobarbaz')
'f-o-o-b-a-r-b-a-z'

new_item will grow bigger and bigger, and since you keep adding it between each 
character of the item, Python will soon run out of memory:
>>> 'newitem'.join('foobarbaz')
'fnewitemonewitemonewitembnewitemanewitemrnewitembnewitemanewitemz'

You probably want to add the items to a new list, and after the for loop you 
just need to do '; '.join(new_list_of_items), or, if you want a ; at the end, 
you can add (item + ';') to the list and then use ' '.join(new_list_of_items).

I also suggest you to use the interactive interpreter to experiment with join.

--
nosy: +ezio.melotti
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30305>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue28596] on Android _bootlocale on startup relies on too many library modules

2017-03-31 Thread Ezio Melotti

Changes by Ezio Melotti <ezio.melo...@gmail.com>:


--
pull_requests: +1113

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28596>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue28596] on Android _bootlocale on startup relies on too many library modules

2017-03-31 Thread Ezio Melotti

Changes by Ezio Melotti <ezio.melo...@gmail.com>:


--
pull_requests:  -1113

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28596>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue28596] on Android _bootlocale on startup relies on too many library modules

2017-03-31 Thread Ezio Melotti

Changes by Ezio Melotti <ezio.melo...@gmail.com>:


--
nosy: +ezio.melotti

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28596>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2771] Test issue

2017-03-24 Thread Ezio Melotti

Changes by Ezio Melotti <ezio.melo...@gmail.com>:


--
Removed message: http://bugs.python.org/msg286498

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue2771>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29891] urllib.request.Request accepts but doesn't check bytes headers

2017-03-23 Thread Ezio Melotti

New submission from Ezio Melotti:

urllib.request.Request allows the user to create a request object like:
  req = Request(url, headers={b'Content-Type': b'application/json'})

When calling urlopen(req, data), urllib will check if a 'Content-Type' header 
is present and fail to recognize b'Content-Type' because it's bytes.
urrlib will therefore add the default Content-Type 
'application/x-www-form-urlencoded', and the request will then be sent with 
both Content-Types.  This will result in difficult-to-debug errors because the 
server will sometimes pick one and sometimes the other, depending on the order.

urllib should either reject bytes headers, or check for both bytes and strings. 
 The docs also don't seem to specify that the headers should be strings.

--
components: Library (Lib)
messages: 290063
nosy: ezio.melotti, orsenthil
priority: normal
severity: normal
stage: test needed
status: open
title: urllib.request.Request accepts but doesn't check bytes headers
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29891>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29785] Registration link sent via email by the tracker is http

2017-03-10 Thread Ezio Melotti

Ezio Melotti added the comment:

Could you report this to http://psf.upfronthosting.co.za/roundup/meta/ ?

--
assignee:  -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> third party
stage:  -> resolved
status: open -> closed

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29785>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2771] Test issue

2017-02-21 Thread Ezio Melotti

Changes by Ezio Melotti <ezio.melo...@gmail.com>:


--
pull_requests: +192

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue2771>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29608] pip_gui

2017-02-20 Thread Ezio Melotti

Changes by Ezio Melotti <ezio.melo...@gmail.com>:


--
pull_requests:  -170

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29608>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29556] Remove unused #include

2017-02-17 Thread Ezio Melotti

Changes by Ezio Melotti <ezio.melo...@gmail.com>:


--
Removed message: http://bugs.python.org/msg288058

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29556>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



  1   2   3   4   5   6   7   8   9   10   >