[issue39607] Add a parameter to strip, lstrip, and rstrip that treats the first parameter as a full string
New submission from Chris Rogers :
Consider this string:
'mailto:mailto:mailto:m...@example.com'
If you try to remove the mailtos with lstrip('mailto:'), you'll be left with
this:
'n...@example.com'
That's because the three strip functions look at each character separately
rather than as a whole string.
Currently, as a workaround, you have to either use regex or a loop. This can
take several lines of code.
It would be great if the strip functions had a second parameter that lets you
keep the first parameter intact.
You could then use this code to get the desired result:
'mailto:mailto:mailto:m...@example.com'.lstrip('mailto:', true)
>>m...@example.com
--
messages: 361791
nosy: Chris Rogers
priority: normal
severity: normal
status: open
title: Add a parameter to strip, lstrip, and rstrip that treats the first
parameter as a full string
type: enhancement
___
Python tracker
<https://bugs.python.org/issue39607>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36702] test_dtrace failed
will rogers added the comment:
I also encountered this on Scientific Linux 7.4 (Linux
3.10.0-693.11.6.el7.x86_64) while trying to build Python 3.8.0.
I think it is due to differences in versions of 'dtrace' on different platforms.
On my MacOS-X v10.14.6 (Mojave) system, the 'dtrace' command has a -q (quiet
the output) option.
On SL 7.4, it does not. The options are quite different.
This is output and versions from my test run:
./python ./Tools/scripts/run_tests.py
== CPython 3.8.0 (default, Oct 29 2019, 14:37:09) [GCC 4.8.5 20150623 (Red
Hat 4.8.5-16)]
== Linux-3.10.0-693.11.6.el7.x86_64-x86_64-with-glibc2.17 little-endian
== cwd: /opt/Python-3.8.0/build/test_python_30482
== CPU count: 2
== encodings: locale=UTF-8, FS=utf-8
Below is an error from the test log that shows the 'q' option being rejected
from 'dtrace' (linux'):
0:10:16 load avg: 1.79 Re-running test_dtrace in verbose mode
skipped "dtrace(1) failed: ('/usr/bin/dtrace', 'invalid option',
'-q')\nUsage /usr/bin/dtrace [--help] [-h | -G] [-C [-I]] -s File.d [-o
]"
Assuming 'dtrace' is run as a sub-process, the different versions could be
producing very different results.
I attached a (clipped) version of my 'make test' output, it is essentially the
same as sayno996's results.
There are also some error from 'test_nis" which can be ignoed for this issue.
I hope this helps.
--
nosy: +willrogers3
versions: +Python 3.8
Added file: https://bugs.python.org/file48687/make_test-clipped.txt
___
Python tracker
<https://bugs.python.org/issue36702>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37818] Behaviors of binary bitwise operators contradicting documentation
New submission from John Rogers : In Python Language Reference (version 3.7), section 6.9 it states that the arguments of binary bitwise operators must be integers. However, the following expressions work without error: True & False False | True True ^ True Each produces a boolean result (not integer) (False, True, False, respectively). Also I find that mixing booleans and integers does work too, though this time it produces integers. One can easily test it on Python home page's console window. I also tested it on my Linux box running version 3.5.3. So it appears that it has been overlooked for quite some time! As an aside: I do assume that boolean values are *distinct* from integers. If they are not, then my apologies! -- assignee: docs@python components: Documentation messages: 349372 nosy: The Blue Wizard, docs@python priority: normal severity: normal status: open title: Behaviors of binary bitwise operators contradicting documentation type: behavior versions: Python 3.5, Python 3.7 ___ Python tracker <https://bugs.python.org/issue37818> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33636] Unexpected behavior with * and arrays
nathan rogers <nathan.roger...@gmail.com> added the comment: [[], [], [], [], []] How is it expected behavior in python, that when I update position 0, it decides to update positions 1-infinity as well? That is nonsense, and there is not a use case for this behavior. If you have already created the value, you have the value locally, and don't need N-REFERENCES to that thing. When calling functions as well, there will never be a time when you need more than 1 reference to the thing. How is this useful, and in what context could this ever be intuitive? If this is not a bug, it countermands the zen of python on almost every alternate line. -- status: closed -> open ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33636> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33636] Unexpected behavior with * and arrays
nathan rogers <nathan.roger...@gmail.com> added the comment: Can anyone give me a legitimate answer as to why this would be expected behavior? When at any point would you ever need that? If the list is local, you already have the thing. If it isn't local, you can pass it to a function by reference. So then, why would you ever need N references to the same thing? Are you going to run out? Are your functions buying tickets to the reference of my thing show, and you're afraid those tickets will run out? What is this? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33636> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33636] Unexpected behavior with * and arrays
New submission from nathan rogers <nathan.roger...@gmail.com>: https://repl.it/repls/ColorfulFlusteredPercent Here you can see the unexpected behavior I was speaking of. This behavior is NOT useful compared to the expected behavior. If I reference position 0 in the array, I expect position 0 to be appended. The sensible behavior, from my view, would be to make n unique values, not n duplicates. -- messages: 317572 nosy: nanthil priority: normal severity: normal status: open title: Unexpected behavior with * and arrays type: behavior versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33636> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14704] NameError Issue in Multiprocessing
New submission from David M. Rogers dmr...@sandia.gov: Python Devs, There is an issue relating to variable lookup using exec from within multiprocessing's fork()-ed process. I'm attempting to use the forked process as a generic remote python shell, but exec is unable to reach variables from within functions. This issue makes it impossible to define a function which uses un-passed variables defined in the remote process. The simplest way to reproduce the error is: --- err.py --- from multiprocessing import Process, Pipe def run_remote(con, name): my_name = name for i in range(2): code = con.recv() exec code me, he = Pipe() p = Process(target=run_remote, args=(he, Sono Inglese de Gerrards Cross.)) p.start() me.send(print my_name) # works me.send( def show_name(): print my_name show_name() # doesn't work ) --- end err.py --- This program prints: $ python2.6 err.py Sono Inglese de Gerrards Cross. Process Process-1: Traceback (most recent call last): File /sw/lib/python2.6/multiprocessing/process.py, line 232, in _bootstrap self.run() File /sw/lib/python2.6/multiprocessing/process.py, line 88, in run self._target(*self._args, **self._kwargs) File err.py, line 7, in run_remote exec code File string, line 4, in module File string, line 3, in show_name NameError: global name 'my_name' is not defined I'm using Mac OSX (10.6.8) and Python 2.6.5 (r265:79063, Sep 23 2010, 14:05:02) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin The issue (with the same traceback) also occurs for: Python 2.7 (r27:82500, Sep 29 2010, 15:34:46) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Using exactly the same set of exec calls locally results in the correct behavior. --- noerr.py --- my_name = Sono Inglese de Gerrards Cross. exec print my_name exec def show_name(): print my_name show_name() --- end noerr.py --- -- components: None messages: 159764 nosy: frobnitzem priority: normal severity: normal status: open title: NameError Issue in Multiprocessing versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14704 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12930] reindent.py inserts spaces in multiline literals
Jonathan Rogers jonathanrrog...@gmail.com added the comment: I don't think reindent.py should change any bytes inside string literals since it can't know anything about what those strings mean or how they'll be used by the program at run time. Unfortunately, it starts out by unconditionally calling the .expandtabs() method on each input line, so tab characters are lost. The only change to a string literal I can imagine that would be safe is to replace tab characters with '\t'. I am trying to use reindent.py on Python source files which include triple-quoted, multi-line string literals containing makefile and Python snippets. In both cases, running reindent.py changes the meaning of of that contained in the literal. -- nosy: +Jonathan.Rogers ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12930 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12930] reindent.py inserts spaces in multiline literals
Jonathan Rogers jonathanrrog...@gmail.com added the comment: Rather than expanding tab characters inside string literals, it's safer to replace them with '\t'. -- Added file: http://bugs.python.org/file24120/save_strings.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12930 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1284316] Win32: Security problem with default installation directory
Fran Rogers f...@dumetella.net added the comment: I'd like to concur that Python should install to %ProgramFiles% by default. The root-directory default is particularly anomalous on 64-bit Windows, where you have separate 64- and 32-bit Program Files directories; if I have a Python installation in C:\Python26, is it amd64 Python or x86 Python? If I want to install both (since many packages don't yet support amd64), which one should I install to \Python26 and which should I rename? As mel's post above (2005-11-15 11:39) points out, installing to C:\ is comparable to installing to /python2.6 on a Unix box; it's nonstandard, inelegant, and prone to ACL problems like the one this bug was opened for. If convenience on the command line (for non-power-users unfamiliar with %Path%) is the concern, a better solution would be a checkbox in the installer to add the new Python to the system %Path%. -- nosy: +fran.rogers ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1284316 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
