[issue23119] Remove unicode specialization from set objects
Raymond Hettinger added the comment: Attaching an alternative patch that handles the unicode specific case with far less code and less overhead. It seems to speed-up all the timings I've tried. It keeps the unicode_eq() specific path which bypasses several unneeded steps: * an incref/decref of the startkey * an incref/decref of Py_True or Py_False * Py_Enter/LeaveRecursive call overhead * A NotImplemented check * Various indirections, null checks, xor bool result, and several nested function calls that save and restore registers * Test for an error result * Test for changed table or entry usual incref/decref, richbool, richcmp, tablesize_change, errorcheck, recursion depth, check for NotImplemented, conv to PyTrue/False, incr/dec Py_True/Py_False, conv back to int } -- Added file: http://bugs.python.org/file37552/move_unicode_inside.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23119 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23123] Only READ support for Decimal in json
Raymond Hettinger added the comment: Given that json is multi-language format ... I don't know that we can expect much more from it. JSON specifies a textual number format but doesn't dictate whether that format represents a fixed precision binary float point number or a decimal floating point number. It is perfectly reasonable for someone to want to read and write a JSON number format to and from a decimal (we also see this with database formats as well -- such as sqlite). This bug report isn't a JSON spec issue; rather, it is about how the JSON module API can support (or inhibit) valid use cases. AFAICT, the patch to make the API better support enums had the side-effect of inhibiting the APIs ability to support number objects that want to control their output via __str__ or __repr__. This seems to block-off decimal support and support for controlling displayed precision. I think the Enum patch is suspect and could be considered a regression. That said, we could simply add direct support for decimals and leave the enum patch in-place (though it still impairs a user's ability to control the displayed precision). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23123 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23123] Only READ support for Decimal in json
Anders Rundgren added the comment: I guess my particular requirement/wish is unusual (keeping the original textual representation of a floating point number intact) while using Decimal should be fairly universal. If these things could be combined in a Decimal support option I would (of course) be extremely happy. They do not appear to be in conflict. Currently I'm a bit bogged down by the crypto-stuff since it is spread over different and incompatible modules which makes it awkward creating a nice unified RSA/EC solution. I may end-up writing a wrapper... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23123 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19548] 'codecs' module docs improvements
Nick Coghlan added the comment: I started making a few edits based on Zuo and Walter's comments while getting this patch ready for merging, and decided the end result could benefit from an additional round of feedback before committing it. This particular patch is also aimed at the Python 3.4 maintenance branch rather than at trunk - the introduction of the new namereplace error handler in 3.5 means that the previous patch didn't apply cleanly to the maintenance branch. While Zoinkity's feedback is also valid (i.e. multibyte codecs aren't documented properly, custom codec registration is both harder than it really should be and not well documented), I think those are better filed and handled as separate issues, rather than trying to handle them here as part of the general bring the current content of the codec module documentation up to date with the current state of Python 3. -- assignee: docs@python - ncoghlan stage: patch review - commit review Added file: http://bugs.python.org/file37553/issue19548-codecs-doc.py34.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19548 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23123] Only READ support for Decimal in json
Bob Ippolito added the comment: I don't think it's reasonable to expect Decimal to always output precisely the same string it was given. It's a waste of complexity and space and the only time you would want this behavior is when you really should've left it accessible as a string in the first place. It sounds like the spec for that signature may be poorly designed (with regard to portability). Relying on the precise string output of a number is not going to work in any JSON parser I've ever seen. You'd need to work at the tokenizer level and not all of the parsers provide an interface at that layer (since many of them combine tokenization and parsing). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23123 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23123] Only READ support for Decimal in json
Anders Rundgren added the comment: Bob, Your'e right, I have put up a requirement for JSON serializing that may be over the top. OTOH, there are (AFAICT...) only two possible solutions: 1. Outlaw floating point data from the plot 2. Insist that serializers conform to the spec As a pragmatic I have settled on something in between :-) https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html#Interoperability I don't think that the overhead in Decimal would be a problem but I'm not a Python platform maintainer so I leave it to you guys. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23123 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23123] Only READ support for Decimal in json
Anders Rundgren added the comment: Well, I could have insisted on canonicalization of floating-point data but that's so awkward that outlawing such data is a cleaner approach. Since the target for JCS is security- and payment-protocols, I don't think the absence of floating-point support will be a show-stopper. I does though make the IETF folks unhappy. Another reason for still wanting it to work as currently specified is because it would be nice to have JCS running on three fully compatible platforms, including one which I haven't designed :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23123 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23103] Reduce memory usage for ipaddress object instances
Nick Coghlan added the comment: I've retitled this issue to be specifically about reducing the memory consumption of the existing types in the IP Address module, as that's a change that isn't easily implemented externally, and shouldn't have any negative side effects under intended usage (although we should probably consider keeping __weakref__ support when adding the __slots__ definitions - I'm OK with taking away arbitrary attribute support, but far more wary of removing the existing weakref support) By contrast, interning for even more aggressive memory usage reduction is something that can be implemented relatively easily externally, and is also something that is really hard to tune in the general case. Small integers and strings that look like identifiers are a win because of the way the language itself works, but there's no similar general purpose heuristic that applies for caching of IP addresses. -- title: ipaddress should be Flyweight - Reduce memory usage for ipaddress object instances ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23103 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23102] distutils: isinstance checks fail with setuptools-monkeypatched Extension/Distribution
Greg Turner added the comment: Here's the same deal more-or-less for issue 23114... this time I expended considerably less effort verifying that it's not a bad idea. At a glance, though, it looks fine, and solved an instance of the issue 23114 problem I was able to repro on my box. Patch context reduced so as to be applicable to all three pythons in one go. -- Added file: http://bugs.python.org/file37554/distutils_accomodate_distribution_ducktypes.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23102 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23102] distutils: isinstance checks fail with setuptools-monkeypatched Extension/Distribution
Greg Turner added the comment: Perhaps it is worth addressing, briefly, the following hypothetical question, as a litmus test against the faint dis-encapsulation code-smell some folks might be picking up from this: In a hypothetcial world without setuptools, would these changes have merit? I'd say, technically, yes. In the Extension case, we are just really trying to ask, is it a tuple, and in the Distribution case, Can we use this thing to finalize/reinitialize Commands?, so, in theory, at least, these isinstance() checks are less pythonic than the hasattr checks in my patches. That stated, I think isinstance was the sensible way to code this in a vacuum, and obviously, I would never have thought this was a fantastic and self-evident proposal, were it not for these setuptools problems. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23102 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23127] socket.setsockopt() is still broken for multicast TTL and Loop options
New submission from Bertrand Janin:
Since I can't re-open issue 3372, I'm opening a new issue. socket.setsockopt()
still sets an optlen of '4' in the setsockopt() system call for options
IP_MULTICAST_TTL and IP_MULTICAST_LOOP. On OpenBSD, this causes the kernel to
hit an error condition and set errno 22 when these options are set:
socket.error: (22, 'Invalid argument')
According to both FreeBSD and OpenBSD manual pages (see e.g.
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/ip.4), these fields
are in fact both 8 bit unsigned, and the manuals suggest the following:
u_char ttl; /* range: 0 to 255, default = 1 */
setsockopt(s, IPPROTO_IP, IP_MULTICAST_TTL, ttl, sizeof(ttl));
The following updated patch for branch 2.7 passes a shorter optlen for
certain Multicast options, it was tested on OpenBSD, Linux and OSX and was
initially proposed by niallo:
diff -r 88de50c1696b Modules/socketmodule.c
--- a/Modules/socketmodule.cSun Dec 28 18:51:25 2014 +0200
+++ b/Modules/socketmodule.cMon Dec 29 08:27:24 2014 -0500
@@ -1879,26 +1879,29 @@
static PyObject *
sock_setsockopt(PySocketSockObject *s, PyObject *args)
{
int level;
int optname;
int res;
char *buf;
int buflen;
int flag;
if (PyArg_ParseTuple(args, iii:setsockopt,
level, optname, flag)) {
+buflen = sizeof flag;
+/* Multicast options take shorter arguments */
+if (optname == IP_MULTICAST_TTL || optname == IP_MULTICAST_LOOP)
+buflen = sizeof(u_char);
buf = (char *) flag;
-buflen = sizeof flag;
}
else {
PyErr_Clear();
if (!PyArg_ParseTuple(args, iis#:setsockopt,
level, optname, buf, buflen))
return NULL;
}
res = setsockopt(s-sock_fd, level, optname, (void *)buf, buflen);
if (res 0)
return s-errorhandler();
Py_INCREF(Py_None);
return Py_None;
--
components: Library (Lib)
messages: 233174
nosy: tamentis
priority: normal
severity: normal
status: open
title: socket.setsockopt() is still broken for multicast TTL and Loop options
type: behavior
versions: Python 2.7, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23127
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23123] Only READ support for Decimal in json
Anders Rundgren added the comment:
Using simplejson I got it to work!!!
I just wonder what you think of the solution:
import collections
import simplejson as json
from decimal import Decimal
class EnhancedDecimal(Decimal):
def __str__ (self):
return self.saved_string
def __new__(cls, value=0, context=None):
obj = Decimal.__new__(cls,value,context)
obj.saved_string = value
return obj;
jsonString = '{t:6,h:4.50, g:text,j:1.40e450}'
jsonObject = json.loads(jsonString,
object_pairs_hook=collections.OrderedDict,parse_float=EnhancedDecimal)
for item in jsonObject:
print jsonObject[item]
print json.dumps(jsonObject)
6
4.50
text
1.40e450
{t: 6, h: 4.50, g: text, j: 1.40e450}
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23123
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11245] Implementation of IMAP IDLE in imaplib?
Gereon Kremer added the comment: So, let's resurrect this one. For the project that lead to the old patch, we did not need this feature. However, we now needed are more complete implementation of IDLE. Hence, we extended this to return after sending idle() and support polling, leaving idle mode or wait until something happens (like before). -- Added file: http://bugs.python.org/file37555/imapidle.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11245 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23128] Key presses are doubled in Tkinter dialog invoked from window close handler (OS X only)
New submission from Philipp Emanuel Weidmann:
Minimal code example:
from Tkinter import Tk
from tkSimpleDialog import askstring
def close_handler():
askstring('', '')
root.destroy()
root = Tk()
root.protocol('WM_DELETE_WINDOW', close_handler)
root.mainloop()
Closing the main window brings up the askstring dialog. *When run on OS X*
(Yosemite, default Python and Tkinter version), each key press on the dialog's
input field is doubled (thus when typing abc what will actually be entered is
aabbcc). On Linux (Python + Tkinter 2.7.8) the problem does not occur. When
the dialog is invoked from outside the close handler, the problem does not
occur.
This bug is causing a downstream issue in the quicksafe system
(https://github.com/p-e-w/quicksafe/issues/2).
--
components: Tkinter
messages: 233177
nosy: pew
priority: normal
severity: normal
status: open
title: Key presses are doubled in Tkinter dialog invoked from window close
handler (OS X only)
type: behavior
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23128
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23129] sqlite3 COMMIT nested in SELECT returns unexpected results
New submission from Jim Carroll:
I reported this to the sqlite mailing list, and the comments I received
suggested the problem may by the python sqlite connector issue, so I'm opening
this as a bug report.
I understand that performing a SELECT and nested COMMIT on the same table is
not supported in sqlite, but I would have expected a COMMIT on a separate table
would not be a problem. Some test code in python however reveals that
performing the COMMIT disrupts the SELECT statement, and causes duplicate data
to be returned.
If this is not a supported operation, would you mind pointing me to the docs so
I can understand it better?
Example
#!/usr/bin/env python
import sqlite3 as sq
db = sq.connect(':memory:')
db.execute('CREATE TABLE tbl (col INTEGER)')
db.execute('CREATE TABLE tbl2 (col INTEGER)')
db.executemany('INSERT INTO tbl (col) VALUES (?)', [(0,), (1,), (2,)])
db.commit()
print('count=' + str(db.execute('SELECT count(*) FROM tbl').fetchone()[0]))
# Read and print the values just inserted into tbl
for col in db.execute('SELECT col FROM tbl'):
print(col)
db.execute('INSERT INTO tbl2 VALUES (?)', col)
db.commit()
print('count=' + str(db.execute('SELECT count(*) FROM tbl').fetchone()[0]))
The output we see is:
count=3
(0,)
(1,)
(0,)
(1,)
(2,)
count=3
The expected output was:
count=3
(0,)
(1,)
(2,)
count=3
Tested on Linux:
sqlite version 3.7.13
sqlite3 connector version 2.6.0
# uname -a
Linux hostname 3.16-0.bpo.3-amd64 #1 SMP Debian
3.16.5-1~bpo70+1 (2014-11-02) x86_64 GNU/Linux
Also tested on Windows with identical results
Sqlite version 3.6.21
Windows 7 Professional, 64-bit
--
messages: 233178
nosy: jamercee
priority: normal
severity: normal
status: open
title: sqlite3 COMMIT nested in SELECT returns unexpected results
type: behavior
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23129
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23129] sqlite3 COMMIT nested in SELECT returns unexpected results
R. David Murray added the comment: I'd say you have a bug here of some sort, but I'm not sure if it is a doc bug or a code bug. Commit specifically does *not* reset the cursors, according to the code, but I'm not even sure what resetting a cursor means :) I've poked around the sqlite3 module's code a bit, but not enough to have an answer to this. I do note that a commit does a call to sqlite3_reset on all statements associated with the connection, and I suspect that's where the problem originates. Which probably makes it a doc bug. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23129 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23127] socket.setsockopt() is still broken for multicast TTL and Loop options
Benjamin Peterson added the comment: Just use the extended signature of the setsockopt: mysocket.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, struct.pack(B, desired_ttl)) -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23127 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23119] Remove unicode specialization from set objects
Raymond Hettinger added the comment:
Timings for no_special_hash.diff:
$ ~/cpython/python.exe -m timeit -r7 -s 's={html}' 'html in s'
1000 loops, best of 7: 0.0315 usec per loop
$ ~/nounicode/python.exe -m timeit -r7 -s 's={html}' 'html in s'
1000 loops, best of 7: 0.0336 usec per loop
$ ~/cpython/python.exe -m timeit -r7 -s 's={html}' 'html in s'
1000 loops, best of 7: 0.0316 usec per loop
$ ~/nounicode/python.exe -m timeit -r7 -s 's={html}' 'html in s'
1000 loops, best of 7: 0.0336 usec per loop
$ ~/cpython/python.exe -m timeit -r7 -s 's={1}' '1 in s'
1000 loops, best of 7: 0.0331 usec per loop
$ ~/nounicode/python.exe -m timeit -r7 -s 's={1}' '1 in s'
1000 loops, best of 7: 0.0328 usec per loop
$ ~/cpython/python.exe -m timeit -r7 -s 's={1}' '1 in s'
1000 loops, best of 7: 0.0332 usec per loop
$ ~/nounicode/python.exe -m timeit -r7 -s 's={1}' '1 in s'
1000 loops, best of 7: 0.0328 usec per loop
The unicode specialization in set_add, set_discard, and set_contains
benefits unicode lookups by 7% but impairs other lookups by 1%.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23119
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4431] Distutils MSVC doesn't create manifest file
Matthew Brett added the comment: I think this is a frank bug for Pythons that use MSVC 10+ by default (3.3, 3.4 for example). The lack of the /MANIFEST flag breaks the distutils.ccompiler.CCompiler.link_executable command - see attached setup.py example. The example gives the error main.exe.exe.manifest : general error c1010070: Failed to load and parse the manifest. The system cannot find the file specified. We (http://nipy.org/dipy) ran into this because we were innocently using compilation of a 'main.c' file to an executable to check link flags. -- nosy: +Matthew.Brett Added file: http://bugs.python.org/file37556/setup.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4431 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23123] Only READ support for Decimal in json
Bob Ippolito added the comment: Yeah, that's the hack I was suggesting. I suppose I don't see the point of having a protocol that normalizes *almost* everything. Normalization should be all or nothing. Other options would be to define the signature at the encoded byte level with no normalization (in which case you could use any off the shelf signing), or at the value level and prescribe a specific interpretation for data types. I would've done it at the value level and prescribed that dictionaries should be key sorted, strings dealt with as UTF-8, and numbers as IEEE 754. I would make sure not to depend on the decimal conversion of numbers, and just work with the serialized bit representation in a particular endian (which you can even do efficiently in modern browser JS with Float64Array, DataView and ArrayBuffer). For JS portability it'd probably treat *all* numbers as floats in the same way, whether they had a decimal to begin with or not. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23123 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23123] Only READ support for Decimal in json
Anders Rundgren added the comment: Bob, I'm not sure I understand why you say that JCS requires *almost* full normalization. Using browsers you can generate fully compliant JCS objects using like 20 lines of javascript/webcrypto (here excluding base64 support). No normalization step is needed. But sure, the IETF JOSE WG has taken an entirely different approach and require JSON objects to be serialized and Base64-encoded. Then the Base64 is signed. Boring. And in conflict with complex messaging like: https://openkeystore.googlecode.com/svn/wcpp-payment-demo/trunk/docs/messages.html#UserAuthorizesTransaction Thanx anyway, I'm pretty happy with how it works now! Well, if Decimal didn't manipulate its argument I would be even happier :-) because then there wouldn't even be a hack. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23123 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23129] sqlite3 COMMIT nested in SELECT returns unexpected results
Jim Carroll added the comment: Hi David, One more data point. Although I demonstrated the bug using the .execute() method associated with a connection object -- you can also create the exact problem using the .execute() method associated with cursors. This leaves no means to COMMIT inside a nested SELECT. The members of the sqlite mailing list confirmed they had no problem executing the SQL statements using C and PHP. I think this is a bug, rather than just a problem with the docs. I've been digging around the pysqlite C source but can't quite figure out what's going on yet. Jim -Original Message- From: R. David Murray [mailto:rep...@bugs.python.org] Sent: Monday, December 29, 2014 1:08 PM To: j...@carroll.com Subject: [issue23129] sqlite3 COMMIT nested in SELECT returns unexpected results R. David Murray added the comment: I'd say you have a bug here of some sort, but I'm not sure if it is a doc bug or a code bug. Commit specifically does *not* reset the cursors, according to the code, but I'm not even sure what resetting a cursor means :) I've poked around the sqlite3 module's code a bit, but not enough to have an answer to this. I do note that a commit does a call to sqlite3_reset on all statements associated with the connection, and I suspect that's where the problem originates. Which probably makes it a doc bug. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23129 ___ -- title: sqlite3 COMMIT nested in SELECT returns unexpected results - sqlite3 COMMIT nested in SELECT returns unexpected results ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23129 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23128] Key presses are doubled in Tkinter dialog invoked from window close handler (OS X only)
Ned Deily added the comment: By default Python, do you mean the Apple supplied Python in /usr/bin? If so, it uses an old Apple supplied Tk 8.5. Can you reproduce the problem with the current python.org 2.7.9 with the current ActiveState Tk 8.5 installed? -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23128 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23123] Only READ support for Decimal in json
Anders Rundgren added the comment: The current JCS validator is only 150 lines and does both RSA and EC signatures: https://code.google.com/p/openkeystore/source/browse/python/trunk/src/org/webpki/json/JCSValidator.py My Java-version is much more advanced but this is quite useful anyway -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23123 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23123] Only READ support for Decimal in json
Ethan Furman added the comment: Raymond Hettinger added the comment: --- This bug report isn't a JSON spec issue; rather, it is about how the JSON module API can support (or inhibit) valid use cases. AFAICT, the patch to make the API better support enums had the side-effect of inhibiting the APIs ability to support number objects that want to control their output via __str__ or __repr__. This seems to block-off decimal support and support for controlling displayed precision. I think the Enum patch is suspect and could be considered a regression. That said, we could simply add direct support for decimals and leave the enum patch in-place (though it still impairs a user's ability to control the displayed precision). The enum patch is in issue18264 if anyone wants to read the discussion. I am not a regular json user, but my impression is the format is pretty basic, and we would be overloading it to try and keep numbers with three decimal places as Decimal, and anything else as float. Isn't json's main purpose to support data exchange between different programs of different languages? Not between different Python programs? -- nosy: +barry, eli.bendersky, ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23123 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23130] Tools/scripts/ftpmirror.py allows overwriting arbitrary files on filesystem
New submission from Guido Vranken: Tools/scripts/ftpmirror.py does not guard against arbitrary path constructions, and, given a connection to a malicious FTP server (or a man in the middle attack), it is possible that any file on the client's filesystem gets overwritten. Ie,. if we suppose that ftpmirror.py is run from a base directory /home/xxx/yyy, file creations can occur outside this base directory, such as in /tmp, /etc, /var, just to give some examples. I've constructed a partial proof of concept FTP server that demonstrates directory and file creation outside the base directory (the directory the client script was launched from). I understand that most of the files in Tools/scripts/ are legacy applications that have long been deprecated. However, if the maintainers think these applications should be safe nonetheless, I'll be happy to construct and submit a patch that will remediate this issue. Guido Vranken Intelworks -- components: Demos and Tools messages: 233189 nosy: Guido priority: normal severity: normal status: open title: Tools/scripts/ftpmirror.py allows overwriting arbitrary files on filesystem type: security versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23130 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23119] Remove unicode specialization from set objects
Changes by Raymond Hettinger raymond.hettin...@gmail.com: Added file: http://bugs.python.org/file37557/measure_build_set.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23119 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23119] Remove unicode specialization from set objects
Changes by Raymond Hettinger raymond.hettin...@gmail.com: Added file: http://bugs.python.org/file37558/build_set_timings.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23119 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23131] saving to file add inexistance characters
New submission from Rosa Maria: I make an xml extractor for mexican internet invoices; the extraction is correct, but when save to csv, some numbers has additional numbers that does not exist, for example 5010.00 is saved as 5010.002. As you can see in the print function at line 155. The problem is in Python 3.4.2 in machines with windows xp, windows 7 and windows 8 It is an small error, but this data is used for Accounting. Thanks in advance and best regards. Rosa Maria -- components: IO files: Python_Send.7z messages: 233190 nosy: Gravitania priority: normal severity: normal status: open title: saving to file add inexistance characters type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file37559/Python_Send.7z ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23131 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23123] Only READ support for Decimal in json
Anders Rundgren added the comment: Ethan Furman added the comment: I am not a regular json user, but my impression is the format is pretty basic, and we would be overloading it to try and keep numbers with three decimal places as Decimal, and anything else as float. Isn't json's main purpose to support data exchange between different programs of different languages? Not between different Python programs? Right, unfortunately the need to support non-native data types like big decimals, dates and blobs have lead to a certain amount of confusion and innovation among JSON tool designers. I (FWIW) do actually NOT want to extend a single bit from the RFC, I just want serializing to be non-invasive. If the parse_float option stays as is it seems that both the people who want big (non-standard) numbers and I who want somewhat non-standard serialization would be happy. I.e. a documentation snippet would be sufficient as far as I can tell. Serialization order of objects is apparently a hot topic https://code.google.com/p/v8/issues/detail?id=164 but Python has no problem with that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23123 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23131] saving to file add inexistance characters
Benjamin Peterson added the comment: That's because line 153 prints extra numbers at the end of the total. -- nosy: +benjamin.peterson resolution: - not a bug status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23131 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
