[issue13761] Add flush keyword to print()
Changes by Cameron Simpson : -- nosy: +cameron ___ Python tracker <http://bugs.python.org/issue13761> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13761] Add flush keyword to print()
Cameron Simpson added the comment: I'm against ignoring a flush failure. What happened to "errors should never pass silently"? IMO, if we get as far as calling flush and having an exception occur, a "more interesting error" hasn't yet occurred. I really dislike things that fail silently. If the caller asks print to flush, and the flush fails, the caller's request has not been met. The caller needs to know or incorrect behaviour can ensue. -- ___ Python tracker <http://bugs.python.org/issue13761> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11633] Document that print may need explicit flushing
Changes by Cameron Simpson : -- nosy: +cameron ___ Python tracker <http://bugs.python.org/issue11633> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13761] Add flush keyword to print()
Cameron Simpson added the comment: Flush can fail of disc full or any number of low level things that prevent the OS getting the data into the on-disc file. Speaking for myself, I certainly want to know if that happens. -- ___ Python tracker <http://bugs.python.org/issue13761> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Changes by Cameron Simpson <[EMAIL PROTECTED]>: -- nosy: +cameron _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1424152> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Cameron Simpson <[EMAIL PROTECTED]> added the comment: Chris, I'm trying your patch out now. My quick reading of it looks ok. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1424152> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Cameron Simpson <[EMAIL PROTECTED]> added the comment: Well I've happily done lots of SOAP transations, admittedly all to the same webservice, via HTTPS-over-proxy-CONNECT using ChrisL's patch. It seems to work just fine. Whom do we petition to get this into the mainline python sources? - Cameron _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1424152> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7776] httplib.py: ._tunnel() broken
New submission from Cameron Simpson :
I'm trying to do HTTPS via a proxy in Python 2.6.4 (which is supposed to
incorporate this fix from issue 1424152).
While trying to debug this starting from the suds library I've been reading
httplib.py and urllib2.py to figure out what's going wrong
and found myself around line 687 of httplib.py at the _tunnel()
function.
_tunnel() is broken because _set_hostport() has side effects.
_tunnel() starts with:
self._set_hostport(self._tunnel_host, self._tunnel_port)
to arrange that the subsequent connection is made to the proxy
host and port, and that is in itself ok.
However, _set_hostport() sets the .host and .port attributes in
the HTTPConnection object.
The next action _tunnel() takes is to send the CONNECT HTTP command,
filling in the endpoint host and port from self.host and self.port.
But these values have been overwritten by the preceeding _set_hostport()
call, and so we ask the proxy to connect to itself.
It seems to me that _tunnel() should be grabbing the original host and port
before calling _set_hostport(), thus:
ohost, oport = self.host, self.port
self._set_hostport(self._tunnel_host, self._tunnel_port)
self.send("CONNECT %s:%d HTTP/1.0\r\n\r\n" % (ohost, oport))
In fact the situation seems even worse: _tunnel() calls send(), send() calls
connect(), and connect() calls _tunnel() in an infinite regress.
- Cameron Simpson
--
components: Library (Lib)
messages: 98264
nosy: cameron
severity: normal
status: open
title: httplib.py: ._tunnel() broken
type: behavior
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue7776>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7776] httplib.py: ._tunnel() broken
Cameron Simpson added the comment: Amendment: regarding the infinite regress, it looks like there will not be a recursion if the caller leaps straight to the .connect() method. However, if they do that then the call to _tunnel() from within connect() will happen _after_ the socket is made directly to the origin host, not via the proxy. So the behaviour seems incorrect then also; it looks very much like _tunnel() must always be called before the real socket connection is established, and .connect() calls _tunnel() afterwards, not before. -- ___ Python tracker <http://bugs.python.org/issue7776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7776] httplib.py: ._tunnel() broken
Cameron Simpson added the comment: It's looking like I have my idea of .host versus ._tunnel_host swapped. I think things are still buggy, but my interpretation of the bug is wrong or misleading. I gather that after _set_tunnel(), .host is the proxy host and that ._tunnel_host is the original target host. I'll follow up here in a bit when I've better characterised the problem. I think I'm letting urllib2's complicated state stuff confuse me too... -- ___ Python tracker <http://bugs.python.org/issue7776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7776] httplib.py: ._tunnel() broken
Cameron Simpson added the comment:
Well, I've established a few things:
- I'm mischaracterised this issue
- httplib's _set_tunnel() is really meant to be called from
urllib2, because using it directly with httplib is totally
counter intuitive
- a bare urllib2 setup fails with its own bug
To the first item: _tunnel() feels really fragile with that recursion issue,
though it doesn't recurse called from urllib2.
For the second, here's my test script using httplib:
H = httplib.HTTPSConnection("localhost", 3128)
print H
H._set_tunnel("localhost", 443)
H.request("GET", "/boguspath")
os.system("lsof -p %d | grep IPv4" % (os.getpid(),))
R = H.getresponse()
print R.status, R.reason
As you can see, one builds the HTTPSConnection object with the proxy's details
instead of those of the target URL, and then put the target URL details in with
_set_tunnel(). Am I alone in find this strange?
For the third, my test code is this:
U = urllib2.Request('https://localhost/boguspath')
U.set_proxy('localhost:3128', 'https')
f = urllib2.urlopen(R)
print f.read()
which fails like this:
Traceback (most recent call last):
File "thttp.py", line 15, in
f = urllib2.urlopen(R)
File "/opt/python-2.6.4/lib/python2.6/urllib2.py", line 131, in urlopen
return _opener.open(url, data, timeout)
File "/opt/python-2.6.4/lib/python2.6/urllib2.py", line 395, in open
protocol = req.get_type()
AttributeError: HTTPResponse instance has no attribute 'get_type'
The line numbers are slightly off because I've got some debugging statements in
there.
Finally, I flat out do not understand urllib2's set_proxy() method:
def set_proxy(self, host, type):
if self.type == 'https' and not self._tunnel_host:
self._tunnel_host = self.host
else:
self.type = type
self.__r_host = self.__original
self.host = host
When my code calls set_proxy, self.type is None. Now, I had naively expected
the first branch to be the only branch. Could someone explain what's happening
here, and what is meant to happen?
I'm thinking that this bug may turn into a doc fix instead of a behaviour fix,
but I'm finding it surprisingly hard to know how urllib2 is supposed to be used.
--
___
Python tracker
<http://bugs.python.org/issue7776>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7776] httplib.py: ._tunnel() broken
Cameron Simpson added the comment:
Well, following your description I've backed out my urllib2 test case to this:
f = urllib2.urlopen('https://localhost/boguspath')
os.system("lsof -p %d | grep IPv4" % (os.getpid(),))
f = urllib2.urlopen(R)
print f.read()
and it happily runs HTTPS through the proxy if I set the https_proxy envvar. So
it's all well and good for the "just do what the environment suggests" use case.
However, my older test:
U = urllib2.Request('https://localhost/boguspath')
U.set_proxy('localhost:3128', 'https')
f = urllib2.urlopen(R)
print f.read()
still blows up with:
File "/opt/python-2.6.4/lib/python2.6/urllib2.py", line 381, in open
protocol = req.get_type()
AttributeError: HTTPResponse instance has no attribute 'get_type'
Now, this is the use case for "I have a custom proxy setup for this activity".
It seems a little dd that "req" above is an HTTPResponse instead of a Request,
and that my be why there's no .ettype() method available.
I also see nothing obviously wrong with my set_proxy() call above based on the
docs for the .set_proxy() method, though obviously it fails.
I think what may be needed is a small expansion of the section in the Examples
are on proxies. There's an description of the use of the *_proxy envvars there
(and not elsewhere, which seems wrong) and an example of providing a proxy
Handler. An addition example with a functioning use of a bare .set_proxy()
might help.
--
___
Python tracker
<http://bugs.python.org/issue7776>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44355] Allow spaces in format strings
Change by Cameron Simpson : -- nosy: +cameron ___ Python tracker <https://bugs.python.org/issue44355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39452] Improve the __main__ module documentation
Change by Cameron Simpson : -- nosy: +cameron ___ Python tracker <https://bugs.python.org/issue39452> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24632] Improve documentation about __main__.py
Change by Cameron Simpson : -- nosy: +cameron ___ Python tracker <https://bugs.python.org/issue24632> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17359] Mention "__main__.py" explicitly in command line docs
Change by Cameron Simpson : -- nosy: +cameron ___ Python tracker <https://bugs.python.org/issue17359> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25625] "chdir" Contex manager for pathlib
Change by Cameron Simpson : -- nosy: +cameron ___ Python tracker <https://bugs.python.org/issue25625> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25625] "chdir" Contex manager for pathlib
Cameron Simpson added the comment: On 15Nov2021 01:04, Python Bug Reports wrote: >Can you share the link? I haven't seen anything recent. Is it under >other thread? It's in the discuss-ideas part of discuss.python.org during a discussions about a possible new context manager to atomically prepare a filename. Latest comment: https://discuss.python.org/t/adding-atomicwrite-in-stdlib/11899/15 and I'm with Inada-san here: I think shutil is a better fit for both the chdir context manager and the thing under discussion. They're both "high level shell-like things" to my mind. -- ___ Python tracker <https://bugs.python.org/issue25625> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36375] PEP 499 implementation: "python -m foo" binds the main module as both __main__ and foo in sys.modules
Cameron Simpson added the comment: I want to start with an apology. I have become a little swamped by work and didn't let anyone know I've made little time for this since March. To my naive eye Nick's snippet looks like it would work for pdb; I became a little stalled there trying to understand how pdb managed the main module. I totally lack the expertise to address pickle; I've never used it and the long history of feature updates sugests to me that I cannot get a deep enough understanding in a meaningful time. -- ___ Python tracker <https://bugs.python.org/issue36375> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36375] PEP 499 implementation: "python -m foo" binds the main module as both __main__ and foo in sys.modules
Cameron Simpson added the comment: Just a remark about the preamble comment: it reads to me as though PEP499 is a misfeature. Possibly change: We actually want the double import, so remove the alias if it exists. to: This module is unusual, and actually wants the double import. Therefore we remove the __spec__.name alias if it exists so that a subsequent import by name will make a distinct instance. Verbose, but at least I know the intent. -- ___ Python tracker <https://bugs.python.org/issue36375> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36375] PEP 499 implementation: "python -m foo" binds the main module as both __main__ and foo in sys.modules
Cameron Simpson added the comment: On 25Nov2019 17:38, Python Bug Reports wrote: >Eric Snow added the comment: > >FWIW, I have some feedback on the PEP. (See msg357448.) Can we discuss here >or should I open a mailing list thread? Let's discuss it here unless it looks like we need wider input. This is related to issue37292 (_xxsubinterpreters: Can't unpickle objects defined in __main__), yes? With PEP499, "python -m foo" should have __name__=='__main__' and __spec__.name=='foo'. Were you thinking the __module__ should come from __spec__.name (and that the PEP should make that clear)? -- ___ Python tracker <https://bugs.python.org/issue36375> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40456] Complete adding silent mode for py_compile
Cameron Simpson added the comment: Since bad input causes py_compile.py to issue an error like this: File "/usr/local/Cellar/python@3.8/3.8.3/Frameworks/Python.framework/Versions/3.8/lib/python3.8/py_compile.py", line 213, in main if quiet < 2: NameError: name 'quiet' is not defined I suggest, to save long review of a larger PR elsewhere, can we please just initially apply a patch like this: [~/src/cpython(git:py_compile-quiet-not-initialised)]fleet2*> diff + exec git diff diff --git a/Lib/py_compile.py b/Lib/py_compile.py index 21736896af..cea851274d 100644 --- a/Lib/py_compile.py +++ b/Lib/py_compile.py @@ -186,6 +186,7 @@ def main(args=None): """ if args is None: args = sys.argv[1:] +quiet = 0 rv = 0 if args == ['-']: while True: Then the runtime issue goes away, and adding the feature fully can be addressed in a more leisurely fashion. -- nosy: +cameron ___ Python tracker <https://bugs.python.org/issue40456> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41787] adding PEP references to documentation
New submission from Cameron Simpson : Add rationale for __length_hint__ and link to PEP 424, per the discussion here: https://mail.python.org/archives/list/python-...@python.org/thread/HXNFMIEZH73MXYEBP4TDIK3KFPYJ4QKR/#CXBEWAYSCAZCU7QABRBTKNVPDM3LELUM Once the phrasing and directives are agreed, continue to chase other references in the docs. This will produce multiple small PRs, possibly one per PEP as chased. Phrasing: I intend to amend the "New in version V." lines to become "New in version V, originally specified by PEPNNN." with a link to the PEP on "PEPNNN". I'm tempted to make "version V" also a link to its Whats New page; that will make for a bit more visual noise but seems pertinent. The other thing I'd like to consider is a _single sentence_ in the docs identifying the main motivating use case for the feature. The __length_hint__ docs are a prime example here - the purpose of the feature is not mentioned, merely its semantics. While a feature can be used for many purposes, knowing why it was introduces brings a lot of cognitive benefit to the reader. -- assignee: docs@python components: Documentation messages: 376914 nosy: cameron, docs@python priority: normal severity: normal status: open title: adding PEP references to documentation ___ Python tracker <https://bugs.python.org/issue41787> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41787] adding PEP references to documentation
Cameron Simpson added the comment:
Re the possible change to "New in version V." text, my proposal there is the
make this become:
New in :ref:`version V `.
by modifying the definitions in sphinxdomains/changset.py from:
versionlabels = {
'versionadded': _('New in version %s'),
'versionchanged': _('Changed in version %s'),
'deprecated': _('Deprecated since version %s'),
}
to:
versionlabels = {
'versionadded': _('New in :ref:`version %s `'),
'versionchanged': _('Changed in :ref:`version %s `'),
}
and adding a:
:: _whatsnew-3.7:
to Doc/whatsnew/3.7.rst and likewise for the other whatsnew files.
That requires a change to both the docs and sphinx, and is independent of the
PEP reference additions. I'll make a distinct PR for this, unrelated to the
other PRs.
In an ideal world we could be more precise by using one of the
_whatsnew37-feature anchors where they are present, but I don't see how to
integrate that into the versionadded directives (absent something quite
intrusive). The above change makes a docs-wide sweep immediately without
additional work.
--
___
Python tracker
<https://bugs.python.org/issue41787>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41787] adding PEP references to documentation
Cameron Simpson added the comment: Argh. I bet that additional %s above won't work :-( -- ___ Python tracker <https://bugs.python.org/issue41787> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41762] Documentation job fails on CIs: duplicate token description of format_spec
Change by Cameron Simpson : -- nosy: +cameron ___ Python tracker <https://bugs.python.org/issue41762> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41787] adding PEP references to documentation
Change by Cameron Simpson : -- keywords: +patch pull_requests: +21324 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22269 ___ Python tracker <https://bugs.python.org/issue41787> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11633] Document that print may need explicit flushing
Cameron Simpson added the comment: Putting the wording into 2.7 might be nice, but I thought it was in bugfix only mode. Regarding UNIX only, I'd avoid it; any file may be buffered in almost any way on any platform. Saying an explicit flush call may be necessary for immediate output is _not_ UNIX only and would be very misleading. Remembering that ~UNIX != Windows. Telling users to explicitly call flush to ensure immediate output where that is necessary ensures portable coding (or ought to, user pigheadedness discounted:-) -- ___ Python tracker <http://bugs.python.org/issue11633> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29949] sizeof set after set_merge() is doubled from 3.5
Changes by Cameron Simpson : -- nosy: +cameron ___ Python tracker <http://bugs.python.org/issue29949> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36375] PEP 499 implementation: "python -m foo" binds the main module as both __main__ and foo in sys.modules
New submission from Cameron Simpson : This issue is to track the implementation of PEP 499 which we hope to get into the upcoming 3.8 release. I've made it because cpython PRs want a bpo number in the subject line. I'll link in the proposed PR once I've filed off a few grammar issues I've just noticed (documentation English grammar). -- components: Interpreter Core messages: 338425 nosy: cameron, ncoghlan priority: normal severity: normal status: open title: PEP 499 implementation: "python -m foo" binds the main module as both __main__ and foo in sys.modules type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36375> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36375] PEP 499 implementation: "python -m foo" binds the main module as both __main__ and foo in sys.modules
Change by Cameron Simpson : -- keywords: +patch pull_requests: +12408 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36375> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36375] PEP 499 implementation: "python -m foo" binds the main module as both __main__ and foo in sys.modules
Cameron Simpson added the comment: I've withdrawn the PR; I hadn't run the full test suite and there are things to fix. - Cameron -- ___ Python tracker <https://bugs.python.org/issue36375> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36375] PEP 499 implementation: "python -m foo" binds the main module as both __main__ and foo in sys.modules
Change by Cameron Simpson : -- pull_requests: +12442 ___ Python tracker <https://bugs.python.org/issue36375> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36375] PEP 499 implementation: "python -m foo" binds the main module as both __main__ and foo in sys.modules
Cameron Simpson added the comment: New PR 12490 attached with a fix for test_pdb. More extensive comments are in the leading comment on the PR itself. - Cameron -- ___ Python tracker <https://bugs.python.org/issue36375> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9527] Add aware local time support to datetime module
Changes by Cameron Simpson : -- nosy: +cameron ___ Python tracker <http://bugs.python.org/issue9527> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15221] os.path.is*() may return False if path can't be accessed
Changes by Cameron Simpson : -- nosy: +cameron ___ Python tracker <http://bugs.python.org/issue15221> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29328] struct module should support variable-length strings
Changes by Cameron Simpson : -- nosy: +cameron ___ Python tracker <http://bugs.python.org/issue29328> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27607] Importing the main module twice leads to two incompatible instances
Cameron Simpson added the comment: On 25Jul2016 02:56, Python Bug Reports wrote: > >Emanuel Barry added the comment: > >I'm fairly sure enums aren't related to this issue, so I'm unassigning Ethan >(but feel free to self-assign back if you so desire :). As I said on IRC (I'm >Vgr), I think that importing a module twice is the problem here, and that PEP >499 is the way to properly solve this and related issues. Thanks for opening >this issue! > >I added Cameron Simpson (PEP 499's author) to the nosy list, hoping he still >wants to work on this (and let us know otherwise). I would personally like to >see the PEP accepted and implemented for 3.6. Thank you; I do want to finish off PEP 499 and get it accepted. I have been very remiss in pursuing that. What can I do to assist here? Cheers, Cameron Simpson -- ___ Python tracker <http://bugs.python.org/issue27607> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19702] Update pickle to take advantage of PEP 451
Changes by Cameron Simpson : -- nosy: +cameron ___ Python tracker <http://bugs.python.org/issue19702> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19251] bitwise ops for bytes of equal length
Changes by Cameron Simpson : -- nosy: +cameron ___ Python tracker <http://bugs.python.org/issue19251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19251] bitwise ops for bytes of equal length
Cameron Simpson added the comment: I'd like speak my support for bitwise ops on bytes and bytearray (agree, on equal lengths only). I've got 2 arguments here: - readability: a ^ b, a | b and so forth are clear and direct - all the various incantation presented must be _understood_, not to mention invented anew by anyone wanting to do they same, with the same burden of getting it correct; of course one can say the same of any feature not already present in a language but that is trite; there are several ways to say this and all have varying degrees of speed, obtuseness and verbosity. And they're all SLOW. Regarding some of the counter arguments in the discussion: - gregory.p.smith in reply to cowlicks: "Security claims? Nonsense. This has nothing to do with security. It is *fundamentally impossible* to write constant time side channel attack resistant algorithms [...]" Maybe cowlicks should have said "reliable", though to my naive eye a normal implementation would be constant time for a given size. I would argue that the clarity and directness of just writing "a^b" immediately makes for trivially correct code, which itself is a necessary prerequisite for secure code. - gregory.p.smith again: "Neither of the above "look as nice" as a simple operator would. But they are at least both understandable and frankly about the same as what you would naively write in C for the task." This is not an argument against the feature. That one had to perform similar activitie in Python as in C merely reflects the present lack of these operators, not a preexisting gleaming sufficiency of operator richness. - Terry J. Reddy: "'XOR of two bytes in one place' strikes me as a thin excuse for a new feature that abbreviates a simple, short, one-liner". Christian Heimes's code has this single example, but anyone wanting to work on chunks of bytes may find themselves here. Just because a lot of things can be written/constructed as one liners doesn't mean they should be operators when (a) the operator is available (==unused) for this type, (b) the meaning of the operator is straight forward and intuitive and (c) any pure Python construction is both wordier and much slower. Anyway, I an for this feature, for the record. -- ___ Python tracker <http://bugs.python.org/issue19251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19251] bitwise ops for bytes of equal length
Cameron Simpson added the comment: Amendment: I wrote above: "Just because a lot of things can be written/constructed as one liners doesn't mean they should be operators". Of course I meant to write "doesn't mean they should _not_ be operators". -- ___ Python tracker <http://bugs.python.org/issue19251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
