[issue39601] brace escapes are not working in formatted string literal format specifications
New submission from JitterMan :
It appears as if escaping the braces by doubling them up is not working
properly if the braces are in a format specification within a f-string.
>>> print(f'Email:\n{C:{{v.name}} {{v.email}}|\n}')
>>>
Traceback (most recent call last):
File "bugreport.py", line 95, in
print(f'Email:\n{C:{{v.name}} {{v.email}}|\n}')
NameError: name 'v' is not defined
The escaping works as expected when the string's format method is used.
--
components: 2to3 (2.x to 3.x conversion tool)
files: bugreport.py
messages: 361702
nosy: jitterman
priority: normal
severity: normal
status: open
title: brace escapes are not working in formatted string literal format
specifications
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48887/bugreport.py
___
Python tracker
<https://bugs.python.org/issue39601>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39601] brace escapes are not working in formatted string literal format specifications
JitterMan added the comment:
It appears as if escaping the braces by doubling them up is not working
properly if the braces are in a format specification within a f-string.
>>> print(f'Email:\n{C:{{v.name}} {{v.email}}|\n}')
>>>
Traceback (most recent call last):
File "bugreport.py", line 95, in
print(f'Email:\n{C:{{v.name}} {{v.email}}|\n}')
NameError: name 'v' is not defined
The escaping works as expected when the string's format method is used.
--
Added file: https://bugs.python.org/file4/bugreport.py
___
Python tracker
<https://bugs.python.org/issue39601>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39601] brace escapes are not working in formatted string literal format specifications
JitterMan added the comment: My expectation is that doubling up the braces acts to escape them, meaning that characters between the braces is treated as simple text and passed to the __format__ method as is. The only processing that should occur on the format specification is to convert the double braces to single braces. The fact that an error occurs saying that 'v' is not defined before the __format__ method is ever called indicates that the contents of the braces are being evaluated as an expression, which fails because v is not defined in the outer scope. Thus the f-string seems to be ignoring the escaping of the braces, but it only does so in the format specifier. -- ___ Python tracker <https://bugs.python.org/issue39601> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39601] brace escapes are not working in formatted string literal format specifications
JitterMan added the comment:
I believe it is worth fixing as it clears up some rather glaring
inconsistenciesā£
and enables a useful capability. Specifically,
1. Formatted string literals and the string format method are currently
inconsistent in the way that they handle double braces in the format
specifier.
>>> x = 42
>>> import datetime
>>> now = datetime.datetime.now()
>>> f'{now:x{{x}}x}'
'x{42}x'
>>> '{:x{{x}}x}'.format(now)
'x{x}x'
2. Formatted string literals currently seem inconsistent in the way they handle
handle doubled braces.
In the base string doubling the braces escapes them.
>>> f'x{{x}}x'
'x{x}x'
In the replacement expression doubling the braces escapes them.
>>> f'{f"x{{x}}x"}'
'x{x}x'
In the format specifier doubling the braces does not escape them.
>>> f'{now:x{{x}}x}'
'x{42}x'
3. Currently there is no way I know of escape the braces in the format
specifier.
4. Allowing the braces to be escaped in the format specifier allows the user to
defer the interpretation of the of a format specifier so that it is
evaluated
by a format function inside the object rather than being evaluated in the
current context. That seems like a generally useful feature.
--
___
Python tracker
<https://bugs.python.org/issue39601>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39601] brace escapes are not working in formatted string literal format specifications
JitterMan added the comment:
Okay, I get it. Someone might be using two braces in the format specifier
because they found that it is a way to both evaluate a sub-expression and get
braces in the formatted result. I was thinking that they would just use three
braces, but that does not appear to work, though I cannot understand the
resulting error message.
>>> x = 42
>>> import datetime
>>> now = datetime.datetime.now()
>>> f'{now:x{x}x}'
'x42x'
>>> f'{now:x{{x}}x}'
'x{42}x'
>>> f'{now:x{{{x}}}x}'
Traceback (most recent call last):
...
TypeError: unhashable type: 'set'
I think you are right. This particular ship may have already sailed away.
--
___
Python tracker
<https://bugs.python.org/issue39601>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39601] brace escapes are not working in formatted string literal format specifications
JitterMan added the comment: Ah, that make sense. Thanks! -- ___ Python tracker <https://bugs.python.org/issue39601> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26096] '*' glob string matches dot files in pathlib
New submission from JitterMan:
Path('.').glob('*') generates all files and directories in '.' including hidden
files (those that begin with '.'). This behavior is inconsistent with the shell
and with the old glob module, which only generate hidden files if the glob
pattern starts with a '.'.
--
messages: 258128
nosy: jitterman
priority: normal
severity: normal
status: open
title: '*' glob string matches dot files in pathlib
type: behavior
versions: Python 3.4
___
Python tracker
<http://bugs.python.org/issue26096>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26113] pathlib p.match('') should return False rather than raising exception
New submission from JitterMan:
One can use '*' as an 'accept all' pattern to match(). It would be nice to also
use '' as a 'reject all' pattern. These 'accept all' and 'reject all' rules are
useful as defaults. Currently passing '' to match() causes an exception. While
it is easy enough to catch the exception, the need to constrains the way
match() must be called and makes the calling code needlessly complicated and
fussy.
--
files: example.py
messages: 258216
nosy: jitterman
priority: normal
severity: normal
status: open
title: pathlib p.match('') should return False rather than raising exception
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file41615/example.py
___
Python tracker
<http://bugs.python.org/issue26113>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26096] '*' glob string matches dot files in pathlib
JitterMan added the comment: The same issues applies with '**', where it is harder to work around. The shell version of '**' prunes out hidden files and directories at all levels, whereas the pathlib.glob() includes all hidden directories. Major surgery would be required to filter out hidden files and directories from the output of pathlib.glob(), which would be expensive and complicated. Perhaps an option is called for that would allow pathlib.glob() to prune its search to only non-hidden directories if requested. And if that seems like a good idea, perhaps there could also be options that specify that only files or only directories should be returned. -- ___ Python tracker <http://bugs.python.org/issue26096> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26115] pathlib.glob('**') returns only directories
New submission from JitterMan:
The title says it all.
The shell version of '*' and '**' return both directories and files.
Path('.').glob('*') returns both directories and files, but
Path('.').glob('**') returns only directories. That seems wrong to me.
--
messages: 258223
nosy: jitterman
priority: normal
severity: normal
status: open
title: pathlib.glob('**') returns only directories
type: behavior
versions: Python 3.5
___
Python tracker
<http://bugs.python.org/issue26115>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26113] pathlib p.match('') should return False rather than raising exception
JitterMan added the comment: I don't know that passing '' as a pattern to glob() makes much sense, but it is useful when passed to match(). Doing so allows me to build a filter that can easily and naturally be disabled. For example, the following allows me to get all the items in a directory that both match a select pattern and do not match a reject pattern: def ls(dir, select='*', reject='.*'): return (p for p in dir.glob(select) if not p.match(reject)) By default this function does not return hidden files or directories. It would seem like this restriction could be removed by passing reject='', but that generates an exception. Working around the exception makes the code noticeably more complicated. Perhaps the question should really be 'what is the benefit of raising an exception when an empty glob string is encountered?'. I cannot think of any. -- ___ Python tracker <http://bugs.python.org/issue26113> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26115] pathlib.glob('**') returns only directories
JitterMan added the comment: It may be what the documentation says it will do, but is not what it should do. I believe that because: 1. Currently ** in pathlib matches only directories, but **.py matches files. That seems inconsistent. 2. In bash, and csh, ** matches files and directories. To get the same in pathlib one must use **/*, which is inconsistent with what we have used for many decades. 3. With the traditional meaning of **, it is easy to constrain the match to directories by adding slash to the end of the glob (just use **/). 4. There is considerable value in supporting the traditional meaning of glob strings. Globbing is a very powerful feature, and it is often offered to the end user in shell-like situations. For example, sftp offers globbing. When offering globbing to the end users it is best to be consistent the globbing they are already familiar with. 5. There is no significant advantage to the difference between pathlib globbing and traditional globbing. Globbing in pathlib is different from traditional globbing in another important way. pathlib does not distinguish between hidden files and directories and normal files and directories. There may be isolated cases where that is preferred, but generally that is not true. Indeed, the primary characteristic of being hidden is that it should not be included in globbing. One marks a file or directory to be hidden specifically to mean 'do not include this one when selecting groups of files or directories'. Once the glob string has been expanded, it is possible to filter out the hidden files and directories, but it very difficult to do if there are several levels of directories because when weeding out the matches that should not be be included you have to look for hidden items at all levels of the path. Globbing has been available and largely unchanged for almost 50 years. I encourage you to strongly consider making pathlib globbing more consistent with what we have all grown up with. -- ___ Python tracker <http://bugs.python.org/issue26115> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26096] '*' glob string matches dot files in pathlib
JitterMan added the comment: Globbing has been with us for almost 50 years, and in all that time it has never matched the hidden files/directories. There may be isolated cases where matching the hidden items is preferred, but generally that is not the case. Indeed, the primary characteristic of being hidden is that it should not be included in globbing. One marks a file or directory to be hidden specifically to mean 'do not include this one when selecting groups of files or directories'. Once the glob string has been expanded, it is possible to filter out the hidden files and directories, but it very difficult to do so if there are several levels of directories because one has to look for hidden items at all levels of the path. Globbing has been available and largely unchanged for almost 50 years. I am not the one that is asking for it to be changed. I am asking for it to be returned to what it has always been. Being consistent with bash and other shells is a very important feature. It allows us to offer pathlib globbing to the end user and have it work the way they expect. -- ___ Python tracker <http://bugs.python.org/issue26096> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24171] httplib
New submission from JitterMan: In python2.7.9, httplib.py, on line 780, makes a call to: line = response.fp.readline(_MAXLINE + 1) This ends up calling a function defined on line 1362 in the same file: def readline(self): Notice the argument mismatch. The call passes two arguments, but the function defines only one. This can be 'fixed' by changing the definition to: def readline(self, size=None): -- messages: 242998 nosy: jitterman priority: normal severity: normal status: open title: httplib type: crash versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue24171> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17849] Missing size argument in readline() method for httplib's class LineAndFileWrapper
JitterMan added the comment: I ran into this problem when I gave https_proxy an invalid value: export https_proxy=http://foo.com No divine intervention required. I was just trying to determine what message was printed with the proxy environment variable was set incorrectly. Perhaps that will help you develop a more reasonable testcase. -- ___ Python tracker <http://bugs.python.org/issue17849> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
