[issue29328] struct module should support variable-length strings
Elizabeth Myers added the comment: Also, to add to the discussion: * Rejecting this because "it doesn't cover every use case" is a red herring at best. If this can't cover your use case, odds are the struct module can *never* cover it. That is no reason to reject it alone; you would need something more heavyweight than the struct module anyway. * If the module can't cover your use case with this feature, it can't cover it right now, so why obstruct it? It covers my use cases for it just fine. * Not everyone needs something more heavyweight, or wants to import some bigger module just because they need variable-length strings. * If the real goal is to discourage use of the struct module, too bad. People are actually using it in production and it serves its (rather small) purpose very well. Other people would like to use the module for their use cases, but presently cannot, and this proposal would help cover their particular cases. * The fact that the netstruct module exists with this feature is proof enough there's demand; not to mention the discussion on the python-ideas ML shows that many people already would find this very useful. It's not like I'm proposing adding braces or some horrible huge proposal, I'm adding two format specifiers. *Two.* -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29328> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29328] struct module should support variable-length strings
Elizabeth Myers added the comment: Hi, After discussing this on the python-ideas ML a bit more, this is actually a feature people want a great deal. It can't cover every use case, but to expand it further than this proposal and make it do so is way beyond the scope of this proposal. It may not be completely useful for every protocol, but it is sufficiently useful for many people who have simpler use cases. There is no reason to prevent the addition of this feature other than what boils down to "well code will have to be written..." I don't buy the argument that it's "outside the scope of the module" more than I think it's more "I don't like the idea of struct being used for non-fixed data." C structures support zero-terminated char arrays, and there is already a Pascal string type. I didn't realise there'd be this much opposition to just adding two format specifiers... :/ -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29328> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29328] struct module should support variable-length strings
New submission from Elizabeth Myers: There was some discussion on python-ideas about this, and I figured it would be more productive to bring it here since to me this appears to be a glaring omission. The struct module has no capability to support variable-length strings; this includes null-terminated and Pascal-ish strings with a different integer datatype (usually in binary) specifying length. This unfortunate omission makes the struct module extremely unwieldy to use in situations where you need to unpack a lot of variable-length strings, especially iteratively; see https://mail.python.org/pipermail/python-ideas/2017-January/044328.html for why. For zero-terminated strings, it is essentially impossible. It's worth noting many modern protocols use variable-length strings, including DHCP. I therefore propose the following extensions to the struct module (details can be bikeshedded over :P): - Z (uppercase) format specifier (I did not invent this idea, see https://github.com/stendec/netstruct - although that uses $), which states the preceding whole-number datatype is the length of a string that follows. - z (lowercase) format specifier, which specifies a null-terminated (also known as C style) string. An optional length parameter can be added to specify the maximum search length. These two additions will make the struct module much more usable in a wider variety of contexts. -- components: Library (Lib) messages: 285828 nosy: Elizacat priority: normal severity: normal status: open title: struct module should support variable-length strings type: enhancement versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29328> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29275] time module still has Y2K issues note
Changes by Elizabeth Myers <elizab...@interlinked.me>: -- type: -> enhancement ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29275> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29275] time module still has Y2K issues note
New submission from Elizabeth Myers: It's 2017. I think it's time to remove the Y2K warning from this: https://docs.python.org/3/library/time.html :P. It's 17 years past the sell-by date for that notice. -- assignee: docs@python components: Documentation messages: 285489 nosy: Elizacat, docs@python priority: normal severity: normal status: open title: time module still has Y2K issues note versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29275> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27479] Slicing strings out of bounds does not raise IndexError
Changes by Elizabeth Myers <elizab...@interlinked.me>: -- components: +Interpreter Core ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27479> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27479] Slicing strings out of bounds does not raise IndexError
New submission from Elizabeth Myers: When slicing strings, IndexError is not raised when the slices are out of bounds, even for negative indexes. Like so: >>> "test"[-1000:1000] 'test' >>> "test"[-1000:1] 't' >>> ""[-100:100] '' This seems more like a bug than useful behaviour to me. -- messages: 270147 nosy: Elizacat priority: normal severity: normal status: open title: Slicing strings out of bounds does not raise IndexError versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27479> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27479] Slicing strings out of bounds does not raise IndexError
Changes by Elizabeth Myers <elizab...@interlinked.me>: -- type: -> behavior ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27479> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25767] asyncio documentation section 18.5.2.3.1. (Windows) links to French Wikipedia in English docs
New submission from Elizabeth Myers: The link for HPET in the asyncio documentation (18.5.2.3.1 Windows, final paragraph, see https://docs.python.org/3/library/asyncio-eventloops.html#windows) links to https://fr.wikipedia.org/wiki/High_Precision_Event_Timer for the HPET link even though the document is in English (it should link to the English Wikipedia version instead). -- assignee: docs@python components: Documentation messages: 255598 nosy: Elizacat, docs@python priority: normal severity: normal status: open title: asyncio documentation section 18.5.2.3.1. (Windows) links to French Wikipedia in English docs type: enhancement versions: Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25767> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25727] os.startfile implementation for other OS'es besides Windows
Elizabeth Myers added the comment: I'm not going to reopen that can of worms. Sorry to waste your time. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25727> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25727] os.startfile implementation for other OS'es besides Windows
New submission from Elizabeth Myers: os.startfile can be implemented on other OS'es besides Windows relatively easily (although the operation parameter should probably be limited to Windows; it can be implemented elsewhere, but is probably not worth the trouble). On Unix-like operating systems besides OS X, an attempt to use xdg-open can be used and will attempt to open the file in a chosen program; this is the freedesktop.org standard open utility. See also http://linux.die.net/man/1/xdg-open and https://wiki.archlinux.org/index.php/Xdg-open (not specific to ArchLinux). On OS X, open can be used, with similar results to xdg-open (in fact, xdg-open seems inspired by it). See also https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/open.1.html. -- components: Library (Lib) messages: 255306 nosy: Elizacat priority: normal severity: normal status: open title: os.startfile implementation for other OS'es besides Windows type: enhancement versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25727> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23749] asyncio missing wrap_socket (starttls)
Elizabeth Myers added the comment: > Therefore, the most convenient place to add the new API are *transports*. I had an inkling this was the case, but I didn't know how to go about the creation of a new protocol and transport pair. > I'm hesitant to add this API to Transport; it somehow feels wrong to put such > an implementation-specific thing there. E.g. I presume you can't do this for > an UDP transport. DTLS (basically TLS over any datagram-oriented protocol, including UDP, SCTP, etc.) exists, so this makes sense, although I don't know if asyncio supports it, but the only major protocol I can think of that uses DTLS is WebRTC. In any case, it could potentially make sense for other transport types, if not now, then in the future. -- nosy: +Elizacat ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23749] asyncio missing wrap_socket (starttls)
Changes by Elizabeth Myers elizab...@interlinked.me: -- nosy: -Elizacat ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23749 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23749] asyncio missing wrap_socket
Elizabeth Myers added the comment: After giving this a look over, I think this is over my head. Sorry. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23749 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23749] asyncio missing wrap_socket
Elizabeth Myers added the comment: It seems pretty simple to just make a function that returns a new transport, something like transport = yield from loop.ssl_wrap_transport(transport). I'm not sure how to handle plaintext data left on the wire, though, unless that's not really a consideration (given most (all?) real-world protocols can (and usually do) wait for the SSL handshake before sending more data when STARTTLS has been requested). For the higher-level API, I'm thinking reader, writer = asyncio.ssl_wrap(reader, writer) maybe? You can't have half-closed SSL connections, so you would have to pass them both in. As for replacing the protocol but keeping the transport, what would be the semantics of that? I can't really think of how to do that one. I do know SMTP clears all state, but some protocols might not (IRC is a key example - this isn't usually a problem since you are supposed to negotiate it early on before you log onto the server), so this shouldn't be mandatory. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23749 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23749] asyncio missing wrap_socket
Elizabeth Myers added the comment: Reading the source now (just woke up, sorry!), the new protocol thing makes sense. I'm not sure what to do with the waiter argument or how to handle that. What I'm really trying to think of here is how to handle copying of state. I guess users will just have to do it by hand if they want to do that? I don't know if keeping the same protocol is practical and just wrapping the transport is a good idea :(. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23749 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23749] asyncio missing wrap_socket
Elizabeth Myers added the comment: For what it's worth, IRC has an optional STARTTLS extension which is implemented by some servers. IMAP and SMTP also have STARTTLS as a fundamental component of their protocols. As gc pointed out, LDAP also supports it. IMO this is a pretty glaring omission. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23749 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23749] asyncio missing wrap_socket
Elizabeth Myers added the comment: What needs to be done to make this happen? I can try to implement it. -- nosy: +Elizacat ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23749 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24047] str.startswith and str.endswith should accept multiple arguments.
New submission from Elizabeth Myers: str.startswith and str.endswith should accept multiple arguments when passing in strings. This makes it easier to check if the first character of a string is one of a given option, versus this awkward construction: f = 'abc' 'test'.startswith(tuple(f)) False With my proposal, this could be shortened to 'test'.startswith(*f) for easy testing. This also makes it easier to check if a string begins with one of any combination of matches. -- components: Interpreter Core, Unicode messages: 241912 nosy: Elizacat, ezio.melotti, haypo priority: normal severity: normal status: open title: str.startswith and str.endswith should accept multiple arguments. type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24047 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22380] Y2K compliance section in FAQ is 14 years too old
New submission from Elizabeth Myers: As seen at https://docs.python.org/3/faq/general.html#is-python-y2k-year-2000-compliant; this is 2014 - Y2K compliance hasn't been a relevant topic for, well, 14 years, and I doubt this is a frequently asked question nowadays. The As of August 2003 portion is even out of date (11 years old!). IMHO this ought to be taken out of the docs, unless this is still something people are asking about. -- assignee: docs@python components: Documentation messages: 226678 nosy: Elizacat, docs@python priority: normal severity: normal status: open title: Y2K compliance section in FAQ is 14 years too old type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22380 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6331] Add unicode script info to the unicode database
Elizabeth Myers added the comment: I think this needs to be fixed, then - we need to study why there are so many new records (e.g. what script contributes most new records), and then look for alternatives. The Common script appears to be very fragmented and may be the cause of the issues. One alternative could be to create a separate Trie for scripts. Not having seen the one in C yet, I have one written in Python, custom-made for storing the script database, based on the general idea of a range tree. It stores ranges individually straight out of Scripts.txt. The general idea is you take the average of the lower and upper bounds of a given range (they can be equal). When searching, you compare the codepoint value to the average in the present node, and use that to find which direction to search the tree in. Without coalescing neighbouring ranges that are the same script, I have 1,606 nodes in the tree (for Unicode 7.0, which added a lot of scripts). After coalescing, there appear to be 806 nodes. If anyone cares, I'll be more than happy to post code for inspection. I don't know what this will be used for, but one application is certainly regular expressions. So we need an efficient test whether the character is in the expected script or not. It would be bad if such a test would have to do a .lower() on each lookup. This is actually required for restriction-level detection as described in Unicode TR39, for all levels of restriction above ASCII-only (http://www.unicode.org/reports/tr39/#Restriction_Level_Detection). -- nosy: +Elizacat ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6331 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21975] Using pickled/unpickled sqlite3.Row results in segfault rather than exception
Elizabeth Myers added the comment: The backtrace of the crash, if it helps -- Added file: http://bugs.python.org/file35948/trace.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21975 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21975] Using pickled/unpickled sqlite3.Row results in segfault rather than exception
New submission from Elizabeth Myers: Pickling, unpickling, then using an sqlite3.Row object results in a segfault on at least Python 3.3.5, 3.4.0, and 3.4.1. I have attached a test case and a backtrace below. I know you're not supposed to pickle sqlite3.Row objects, as the given test case below results in an exception to the effect that sqlite3.Row objects cannot be pickled in Python 2.7. I don't think a segfault is the desired behaviour, however... -- components: Library (Lib) files: testcase.py messages: 222982 nosy: Elizacat priority: normal severity: normal status: open title: Using pickled/unpickled sqlite3.Row results in segfault rather than exception type: crash versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file35947/testcase.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21975 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21031] [patch] Add AlpineLinux to the platform module's supported distributions list
Elizabeth Myers added the comment: Any information or updates? :) -- status: open - languishing ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21031 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21031] [patch] Add AlpineLinux to the platform module's supported distributions list
New submission from Elizabeth Myers:
This patch adds support for the AlpineLinux distrubtion
(http://alpinelinux.org) to the platform.linux_distributions function, e.g.:
platform.linux_distribution()
('alpine', '2.8.0_alpha2', '')
Thoughts, feelings, and rotten tomatoes welcome :).
--
components: Library (Lib)
files: platform.patch
keywords: patch
messages: 214545
nosy: Elizacat
priority: normal
severity: normal
status: open
title: [patch] Add AlpineLinux to the platform module's supported distributions
list
versions: Python 3.5
Added file: http://bugs.python.org/file34578/platform.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21031
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21031] [patch] Add AlpineLinux to the platform module's supported distributions list
Changes by Elizabeth Myers elizab...@sporksmoo.net: -- type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21031 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19443] add to dict fails after 1,000,000 items on py 2.7.5
Elizabeth Myers added the comment:
Your test case, nor the one I wrote, trigger Python 2.7.5 nor 3.3.2 on Linux
64-bit:
try: xrange
except: xrange = range
d = {}
r = 1000
ctr = 0
for n in xrange(r):
d[n] = n
ctr += 1
assert len(d) == r
assert ctr == r
--
nosy: +Elizacat
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19443
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
