[issue9625] argparse: Problem with defaults for variable nargs when using choices
paul j3 added the comment: I've added 2 more tests, one with default='c', which worked before. one with default=['a','b'], which only works with this change. http://bugs.python.org/issue16878 is useful reference, since it documents the differences between nargs=? and nargs=*, and their handling of their defaults. -- Added file: http://bugs.python.org/file30709/issue9625_1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9625 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18313] In itertools recipes repeatfunc() defines a non-keyword argument as keyword
Changes by Ned Deily n...@acm.org: -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18313 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18312] make distclean deletes files under .hg directory
Changes by STINNER Victor victor.stin...@gmail.com: -- versions: +Python 3.3 -Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18312 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18312] make distclean deletes files under .hg directory
STINNER Victor added the comment:
Extract of GNU standards:
# make distclean
# Delete all files from the current directory that are created by
# configuring or building the program. If you have unpacked the
# source and built the program without creating any other files,
# `make distclean' should leave only the files that were in the
# distribution.
Python should only remove files generated by the build process: Makefile,
pyconfig.h, *.o, etc. But not files generated by Mercurial (.orig, .rej),
backup files (.old, .bak), nor any other files which is not generated by the
build. These files may be important for the developer (Mercurial keeps modified
files after hg revert --all for example).
If someone wants an hardcore cleaner, the command can be kept, but please,
under a different name.
I use make distclean when I change compiler options (rerun Makefile), when a
new C file is added (calling make is usually not enough, and I prefer to
restart from a clean source tree), or more generally when Python doesn't
compile for an unknown reason. For example, make distclean was need when the
new _stat (Modules/_stat.c) module was added.
R. David Murray wrote on python-dev: We also sometimes ask someone reporting
an issue to do a make distclean and recompile (...).
Here is a patch simply removing the find -exec rm {}; command from make
distclean. Remaining commands:
--
# Make things extra clean, before making a distribution:
# remove all generated files, even Makefile[.pre]
# Keep configure and Python-ast.[ch], it's possible they can't be generated
distclean: clobber
for file in Lib/test/data/* ; do \
if test $$file != Lib/test/data/README; then rm $$file; fi; \
done
-rm -f core Makefile Makefile.pre config.status \
Modules/Setup Modules/Setup.local Modules/Setup.config \
Modules/ld_so_aix Modules/python.exp Misc/python.pc
-rm -f python*-gdb.py
--
--
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file30710/make_distclean.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18312
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18312] make distclean deletes files under .hg directory
Marc-Andre Lemburg added the comment: On 27.06.2013 09:36, STINNER Victor wrote: STINNER Victor added the comment: Extract of GNU standards: # make distclean # Delete all files from the current directory that are created by # configuring or building the program. If you have unpacked the # source and built the program without creating any other files, # `make distclean' should leave only the files that were in the # distribution. Python should only remove files generated by the build process: Makefile, pyconfig.h, *.o, etc. But not files generated by Mercurial (.orig, .rej), backup files (.old, .bak), nor any other files which is not generated by the build. These files may be important for the developer (Mercurial keeps modified files after hg revert --all for example). If someone wants an hardcore cleaner, the command can be kept, but please, under a different name. Hmm, but distclean is exactly the kind of cleaner it's meant to be: you use the command to prepare for a source code distribution and you don't want any backup files or failed patch traces in your source code distribution. Perhaps we should introduce a softer version that leaves the files you mention in untouched, so it can be used by developers, e.g. make devclean. -- nosy: +lemburg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18312 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18309] Make python slightly more relocatable
Mathias Fröhlich added the comment: Hi Eric, Thanks for looking at that ticket so fast! Reassigning this to 3.4 is great. In general, yes I can already do what I need more or less. This is the reason why I can be fine with about every python version. The point I bring up this change that I believe I am doing this at an unappropriate place as I need to know some internals of python when I do so and that I think that other can probably also benefit from this idea/change. What I currently do is to write an application that just uses python*.so as an embedded interpreter and this precompiled application might be relocated to about everywhere - just where it is unpacked. We are currently using the same sort of code to find out where the python*so file is and we use Py_SetPythonHome to set is to the directory where the so file resides. Why are we doing this? So, it takes the idea that is currently in the standard python interpreter. This one tries to be relocatable (means: pack the installation directory and unpack that somewhere else and be still able to run) by looking at argv[0] and dereferencing symbolic links until it arrives at a real file. Now suppose you want to embed python, then you do no longer use the standard python interpreter program. You may also use a different installation layout for basic things like bin and lib. So you end up with an application that is no longer able to find its provided python modules by looking at the applications path. But instead of starting from the path of the interpreter (which is not used in this case) or the application itself you could start from the python library path and look for your python installation relative to that. So as long as you stick with the relative file layout of everything that is python related (and only what is python related, the python.so and the modules) when you pack and unpack your precompiled application this would just work. So, put that in short: Instead of dynamically finding the the python module path relative to .../bin/python try to find the python relative to .../lib/libpython34.so. The benefit of that would be that every application that embeds python and needs to be relocatable will just work in the way that today only the standard python interpreter works. I try to get all of the PEP you pointed me to. As I am seeing this longer document the first time, I am not sure if I missed something there, but in that framework of this my proposal would probably influence the initial setting of sys.prefix (?) if this is not already provided from the embedding application. And yes I am perfectly fine with a different or more general approach. The initially attached patch is something that tried to integrate into the current checked in code as I understood it. Greetings Mathias -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18309 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16487] Allow ssl certificates to be specified from memory rather than files.
Kristján Valur Jónsson added the comment: Thanks for your comments Christian. You don't check ERR_GET_LIB() in some places. Do you have a particular place in mind? About DER. As I understand, currently _ssl only supports PEM. If that is the case, then supporting DER should, IMHO, be a separate patch. It will probably involve adding an argument to the functions. Both DER and PEM files are binary formats. the PEM is base64 encoded ascii with some strict ascii headers and footers. As such, the encoding is quite explicit. I am not sure that automatic conversion from unicode to ascii should be undertaken on the C level, particularly if the intention later is to support DER, which is pure binary and where string has no place. I'll have a look at your patch as well, haven't gotten round to do that yet. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16487 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16487] Allow ssl certificates to be specified from memory rather than files.
Christian Heimes added the comment:
I found two places:
if (ERR_GET_REASON(err) == X509_R_CERT_ALREADY_IN_HASH_TABLE) {
if (ERR_GET_REASON(err) == PEM_R_BAD_BASE64_DECODE)
AFAIK the _ssl module only supports PEM certs for loading. On the other hands
cert data can only be retrieved as dict representation or binary DER data, e.g.
getpeercert(binary_form=True) - DER bytes. It's a bit of a puzzle to me.
It feels a bit strange to treat PEM certs as binary data, especially since the
SSL module treats PEM as ASCII unicode. For example DER_cert_to_PEM_cert()
accepts bytes and returns str, PEM_cert_to_DER_cert() converts str to bytes.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16487
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16487] Allow ssl certificates to be specified from memory rather than files.
Antoine Pitrou added the comment: It feels a bit strange to treat PEM certs as binary data, especially since the SSL module treats PEM as ASCII unicode. For example DER_cert_to_PEM_cert() accepts bytes and returns str, PEM_cert_to_DER_cert() converts str to bytes. I agree that PEM is logically text (i.e. unicode). Also, having the unicode == PEM, bytes == DER distinction sounds reasonably practical. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16487 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13483] Use VirtualAlloc to allocate memory arenas
Changes by Martin v. Löwis mar...@v.loewis.de: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13483 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13483] Use VirtualAlloc to allocate memory arenas
Roundup Robot added the comment: New changeset 44f455e6163d by Martin v. Löwis in branch 'default': Issue #13483: Use VirtualAlloc in obmalloc on Windows. http://hg.python.org/cpython/rev/44f455e6163d -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13483 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16113] Add SHA-3 (Keccak) support
Christian Heimes added the comment: Hi Aaron, it's a tempting idea but I have to decline. The API is deliberately limited to the NIST interface. Once OpenSSL gains SHA-3 support we are going to use it in favor for the reference implementation. I don't expect OpenSSL to provide the full sponge API. I also like to keep all options open so I can switch to a different and perhaps smaller implementation in the future. The reference implementation is huge and the binary is more than 400 KB. For comparison the SHA-2 384 + 512 module's binary is just about 60 KB on a 64bit Linux system. Once a a new API has been introduced it's going to take at least two minor Python release and about four to five years to remove it. But I could add a more flexible interface to Keccak's sponge to my standalone sha3 module https://pypi.python.org/pypi/pysha3 ... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16113 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16487] Allow ssl certificates to be specified from memory rather than files.
Kristján Valur Jónsson added the comment: Ok, thanks. The consistency argument is strong, also Antoine's suggestion to use the return type of read() as a discriminant. also please excuse me because I am not a habitual user of Python 3 and haven't become used to the str/binary dichotomy yet. I didn´t know, for instance, about io.BytesIO until I found to my horror that io.StringIO.read() would output unicode (i.e str). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16487 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16487] Allow ssl certificates to be specified from memory rather than files.
Christian Heimes added the comment: EVE Online is still using Python 2.7? You gotta hurry up or Guido will beat you with Dropbox's 3.x port. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16487 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18312] make distclean deletes files under .hg directory
Eric V. Smith added the comment: My plan is to just fix this issue, right now, by changing the find command to be: find $(srcdir)/[a-zA-Z]* ... That fixes this bug and keeps the current functionality. If someone wants to open another issue about changing what distclean does, I think that's okay. I suggest discussing it on python-dev first. -- assignee: - eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18312 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18309] Make python slightly more relocatable
Nick Coghlan added the comment: The way we figure out where to find the standard library is crazy, and creating the infrastructure to start making it less crazy is actually one of the prime motivations for PEP 432 :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18309 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18314] Have os.unlink remove junction points
New submission from Kim Gräsman: os.unlink currently raises a WindowsError (Access Denied) if I attempt to unlink an NTFS junction point. It looks trivial to allow Py_DeleteFileW [1] to remove junction points as well as proper symbolic links, as far as I can tell. For example, the ntfslink-python library [2] only checks if both FILE_ATTRIBUTE_DIRECTORY and FILE_ATTRIBUTE_REPARSE_POINT are set. RemoveDirectoryW is documented to handle junction points transparently, so it should just be a matter of passing the path on if it's a junction point or a symbolic link. My motivation for this is that I have used external tools to create junction points, and am now switching to symbolic links. When deleting a directory, I need to do: try: os.unlink(link_path) except WindowsError as detail: # BACKWARD COMPATIBILITY HACK if detail.winerror == 5: _delete_junction_point(link_path) else: raise which is a little funky. It seems like os.unlink semantics work just as well for junction points, even if they can't be created with os.symlink. Love it/hate it? [1] http://hg.python.org/cpython/file/44f455e6163d/Modules/posixmodule.c#l4105 [2] https://github.com/Juntalis/ntfslink-python/blob/2f6ff903f9b22942de8aa93a32a3d817124f359e/ntfslink/internals/__init__.py#L32 -- components: Windows messages: 191945 nosy: Kim.Gräsman priority: normal severity: normal status: open title: Have os.unlink remove junction points type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18314 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18314] Have os.unlink remove junction points
Kim Gräsman added the comment: Also, I believe the reason os.unlink raises access denied is because a junction point does not currently qualify as a directory link, so its path is passed directly to DeleteFileW, which in turn refuses to delete a directory. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18314 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18244] singledispatch: When virtual-inheriting ABCs at distinct points in MRO, composed MRO is dependent on haystack ordering
Łukasz Langa added the comment: The reason why I think it's wrong to special-case ABCs that are explicitly in the MRO is that it's only one of four methods of virtual subclassing: 1. Explicit MRO; 2. Abstract functionality implicitly implemented without any form of registration; 3. abc.register(); 4. One of the above on a base of the type in question. This creates more possibilities for conflicts than just the example described in my last message. For instance, what's the preferred ABC here, Iterable or Sized? class E(Sized): ... def __len__(self): ... return 0 ... def __iter__(self): ... for i in []: ... yield i My answer is: neither. E equally is-a Sized and is-a Iterable. If the dispatcher favors one over the other, you will get people upset about the decision, no matter which one it is. Note that the conflict arises only for multiple ABCs which end up *on the same level* of the MRO. For instance in the example below the dispatch always chooses the Iterable implementation (the functionality appears directly on F, whereas Sized appears on a base): class HasSize(Sized): ... def __len__(self): ... return 0 ... class F(HasSize): ... def __iter__(self): ... for i in []: ... yield i If we wanted to favor the ABCs that are explicitly in the MRO, what should we choose in this case? If we say Sized, then it breaks the whole idea of arranging the ABCs next to the class that first implements them in the MRO. But it gets better! Suppose you have a generic function with implementations for Sized and Callable. Which implementation should we choose for class G? class G(MutableMapping): ... def __call__(self): ... return None ... # the rest of the MutableMapping implementation Seems like Sized because it is explicitly in the MRO, right? What about H then? class H(dict): ... def __call__(self): ... return None Well, now it's suddenly Callable because Sized is only a virtual base class. I don't think we should let that happen. It all comes down to the question whether you consider ABCs to be bases FOR REAL or only sort-of-but-not-really. I believe they're real bases regardless of the method of registration. Implicit implementation and abc.register() doesn't make the base any less real. All in all, the user will ask: Hey, it's true, I have a tricky type that subclasses both an ABC1 and an ABC2 and singledispatch raises a RuntimeError. How do I make this work? The answer is simple: just register a more specific implementation on the generic function, even if it simply selects one of the existing ones: generic_func.register(TrickyType, generic_func.dispatch(ABC2)) Explicit is better than implicit. -- Added file: http://bugs.python.org/file30711/issue18244.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18313] In itertools recipes repeatfunc() defines a non-keyword argument as keyword
Eric V. Smith added the comment: I'm not sure what you're saying. Given the function definition, the way you're calling it is incorrect, and the error messages explain why. Are you saying that these ways to call repeatfunc() are documented somewhere that needs fixing? I couldn't find that on the itertools documentation. -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18313 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18313] In itertools recipes repeatfunc() defines a non-keyword argument as keyword
Changes by Eric V. Smith e...@trueblade.com: -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18313 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18313] In itertools recipes repeatfunc() defines a non-keyword argument as keyword
Changes by py.user bugzilla-mail-...@yandex.ru: -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18313 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18313] In itertools recipes repeatfunc() defines a non-keyword argument as keyword
py.user added the comment: it should be: def repeatfunc(func, times, *args): and None for times described in the docstring -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18313 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18313] In itertools recipes repeatfunc() defines a non-keyword argument as keyword
Eric V. Smith added the comment: I see. You can't call repeatfunc() and specify times with a named argument because of *args. Interesting. I'll let Raymond weigh in. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18313 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16251] pickle special methods are looked up on the instance rather than the type
Eric Snow added the comment: A backward compatible solution would be to do lookup on the class after trying the instance (and that came back None or isn't callable). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16251 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18315] bufsize parameter not documented in 2.7.5
New submission from Terrel Shumway: for line in fileinput.input(files,inplace,backup,rU): File /usr/lib/python2.7/fileinput.py, line 253, in next line = self.readline() File /usr/lib/python2.7/fileinput.py, line 346, in readline self._buffer = self._file.readlines(self._bufsize) TypeError: an integer is required According to the documentation, my code was correct. But somewhere along the line, someone added a 'bufsize' parameter and didn't update the docstrings. It's an easy fix, but I'll have to investigate when this broke. -- assignee: docs@python components: Documentation messages: 191952 nosy: Terrel.Shumway, docs@python priority: normal severity: normal status: open title: bufsize parameter not documented in 2.7.5 type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18315 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18315] bufsize parameter not documented in 2.7.5
Terrel Shumway added the comment: http://hg.python.org/cpython/file/4dbbf322a9df/Lib/fileinput.py In the process, I added an optional bufsize argument to the input() function and the FileInput class. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18315 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18315] bufsize parameter not documented in 2.7.5
R. David Murray added the comment: A quick look at the VCS history indicates bufsize has been in there for a long time. The sphinx docs are wrong as well. This is correctly documented in python3, apparently as part of the conversion from [] notation to keyword notation in d143eb624cf5. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18315 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18315] bufsize parameter not documented in 2.7.5
Terrel Shumway added the comment: http://hg.python.org/cpython/file/68c776ba5ea5/Lib/fileinput.py This is where the incorrect docstrings get added. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18315 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18244] singledispatch: When virtual-inheriting ABCs at distinct points in MRO, composed MRO is dependent on haystack ordering
Guido van Rossum added the comment: Hm. I interpret explicit is better than implicit very differently. I see a strict priority ordering from better to worse, in cases that would otherwise be ambiguous: 1. explicit base class (ABC or otherwise) 2. ABC explicitly registered 3. ABC implicitly inferred from presence of special method I'm all for using all the other heuristics and rules you describe: inferred ABCs occur at the level where they are introduced, for example, and if two different ABCs are both inferred at the same level or both registered at the same level, that should be considered ambiguous. But if one ABC is listed as an explicit base at some level and another is registered or implicit at the same level, the explicit base should just win -- just as if both ABCs were explicitly listed, the one listed first wins. So the rule should be that registered and inferred bases are only considered after explicit bases at the same level. (If you want the registered class to be preferred, you should add it as an explicit base instead -- and if you don't own the code, you should respect the choice of its author, or do something using subclassing.) If it were me, explicitly registered ABCs would also trump inferred ABCs -- after all an inferred ABC is far from obvious to most readers and might even be an accident, and the situation can be rectified by explicit registration. IOW, I disagree with your claim that Class C is-a Sized just as well as it is-a Iterable. C is a Sized *more* than an Iterable because Size is an explicitly listed base class and Iterable is added through registration. Same if Iterable were inferred. (Just to be clear, this only applies if the ambiguity occurs at a single level. ABCs explicitly listed, registered, or inferred at some base class have explicitly lower priority.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16487] Allow ssl certificates to be specified from memory rather than files.
Kristján Valur Jónsson added the comment: 2.7 is the pinnacle of pythonic achievement. Particularly our branch of it :) One day we'll move, I'm sure, when there is an opportune moment. For example, if we were to start supporting a new game, a new platform. But for now, if it ain't broke, we won't fix it. In fact, today I was asked about python for the ps4... It might be worth taking a look at porting p3k for that and making a clean break :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16487 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18315] bufsize parameter not documented in 2.7.5
Terrel Shumway added the comment: Here is a patch against the 2.7 branch. It will probably also apply to 2.6 if anyone cares. -- keywords: +patch Added file: http://bugs.python.org/file30712/fileinput-document-bufsize.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18315 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18315] bufsize parameter not documented in 2.7.5
Terrel Shumway added the comment: Oops. I messed up, even on such a tiny fix. #:( -- Added file: http://bugs.python.org/file30713/fileinput-document-bufsize.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18315 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18242] IDLE should not be replacing warnings.formatwarning
Changes by Terry J. Reedy tjre...@udel.edu: -- Removed message: http://bugs.python.org/msg191926 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18242 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18242] IDLE should not be replacing warnings.formatwarning
Terry J. Reedy added the comment: See #18101 for patch that will fix this also. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18242 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17580] ctypes: ARM hardfloat argument corruption calling functions with many float arguments
Changes by Christian Heimes li...@cheimes.de: -- versions: +Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17580 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18316] Idle 2.7: update to simply cross-version patches
New submission from Terry J. Reedy: In a commiters-list discussion of heuristics for what patches can go into non-Idle 2.7, Nick Coghlan offered simplifying cross-version maintenance. (He also mentioned addressing issues that arise due to changes in the underlying platforms, which is another issue I will open.) Because of PEP 434 and the subsequent application of most Idle patches to all current versions, cross-version consistency is even more important for idlelib than the rest of the repository. When backporting patches, both context and changed lines must match. My experience so far is that merge conflicts are normal. So I think the latitude for consistency patches to reduce these should be even wider than for the rest of the repository. On the other hand, the current lack of tests suggests more caution than for the rest of the repository. For this issue, I would like to at least change except exception, e: to except exception as e:. This is about as safe as anything, and grepping 2.7 idlelib for except .*, *. yields 23 hits where the ',' is not for multiple exceptions. 2.7 has about 80 print statements. While I would not change all in one patch (maybe 4), all in any file should be changed together when the future import is added at the top. Once this is done, forgetting to add parens or convert ' file' results in a SyntaxError. So this is also pretty safe if the file compiles. Current uses of int() seem to be for str or float conversion, not a/b truncations. That is already done with a//b. There do not seem to be any unicode string literals. Have I forgotten any generic ways to make 2.7 code the same as 3.x? -- files: differ23.py messages: 191961 nosy: ncoghlan, roger.serwy, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Idle 2.7: update to simply cross-version patches versions: Python 2.7 Added file: http://bugs.python.org/file30714/differ23.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18316 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18316] Idle 2.7: update to simply cross-version patches
Terry J. Reedy added the comment: I wrote a short script (already uploded) to differ 2.7 and 3.3 versions of an idlelib file. Applied to PyShell, I see unnecessary differences, like 'a,b' changed to 'a, b', or 'not a in b' changed to 'a not in b' only in 3.3 (probably for 3.0 when the necessary changes were made). When working on a particular file, I would be inclined to make the obvious updates to 2.7 first. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18316 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18316] Idle 2.7: update to simplify cross-version patches
Changes by Terry J. Reedy tjre...@udel.edu: -- title: Idle 2.7: update to simply cross-version patches - Idle 2.7: update to simplify cross-version patches ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18316 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11016] Re-implementation of the stat module in C
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11016 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18217] Deprecate and remove gettext.install
Changes by Jakub Wilk jw...@jwilk.net: -- nosy: +jwilk ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18217 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10529] Write argparse i18n howto
Changes by Jakub Wilk jw...@jwilk.net: -- nosy: +jwilk ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10529 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18317] gettext: DoS via crafted Plural-Forms
New submission from Jakub Wilk: It is possible to craft a MO file with Plural-Forms taking arbitrary amounts of CPU and memory to evaluate. A test case is attached. I realize that opening unstrusted MO files is a rather unusual use case, but the module already contains some code to protect againt malicious Plural-Forms, so I thought you might want to fix this problem as well. -- components: Library (Lib) files: testcase.mo messages: 191963 nosy: jwilk priority: normal severity: normal status: open title: gettext: DoS via crafted Plural-Forms type: security Added file: http://bugs.python.org/file30715/testcase.mo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18317 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18317] gettext: DoS via crafted Plural-Forms
Changes by Jakub Wilk jw...@jwilk.net: Added file: http://bugs.python.org/file30716/testcase.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18317 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14360] email.encoders.encode_quopri doesn't work with python 3.2
Roundup Robot added the comment: New changeset 1d5856849e64 by R David Murray in branch '3.3': #14360: make encoders.encode_quopri work. http://hg.python.org/cpython/rev/1d5856849e64 New changeset 9046ef201591 by R David Murray in branch 'default': Merge #14360: make encoders.encode_quopri work. http://hg.python.org/cpython/rev/9046ef201591 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14360 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14360] email.encoders.encode_quopri doesn't work with python 3.2
Changes by R. David Murray rdmur...@bitdance.com: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14360 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14360] email.encoders.encode_quopri doesn't work with python 3.2
R. David Murray added the comment: This should now be fixed. Calling MIMEApplication with a binary payload and passing it encode_quopri as the encoder will now actually work. -- resolution: - fixed stage: needs patch - committed/rejected versions: +Python 3.4 -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14360 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18318] Idle: stop depending on console output
New submission from Terry J. Reedy: It appears that Idle was originally written to run on *nix after being launched from a command-line console. Messages related to Idle code (warnings and exceptions) are sent back to the console, while messages related to user code go to the shell window. This makes Idle a hybrid text/gui application. Later, Idle was ported to run on Windows with the pythonw.exe no-console binary. When it is started normally for Windows, from anything but a console, there is no console. This has caused problems when Idle tries to write to the non-existent console. (I do not know the situation on modern Mac and *nix.) (Even when a console does exist, it will usually get buried and messages may not be seen.) Example: The warning system, monkey patched in both PyShell.py and run.py and documented in the former. (Edited quote from 3.3.) # Override warnings module to write to warning_stream. # Initialize to send IDLE internal warnings to the console. # ScriptBinding.check_syntax() will temporarily redirect the stream # to the shell window to display warnings when checking user's code. warning_stream = sys.__stderr__ # Typically None, at least on Windows. def idle_showwarning(... ... if file is None: file = warning_stream # Which may itself be None!!! try: file.write(... # AttributeError when file is still None except OSError: pass # if file (probably __stderr__) is invalid, skip warning. The patch for #18081 also catches AttributeError as a bandage. Issue goal: make Idle a true gui app by removing the dependence on a console, which may not exist. Proposed method: re-factor Idle startup to try to import tkinter first, rather than last. If this import fails, inform user with console message and/or the os-specific means to gui apps to tell users 'I cannot start because ...'. I know this exists on Windows because I have seen such messages. I presume same is true on other systems. If this import succeeds, setup traceback and warnings hooks to send internal messages to a gui messagebox rather than (or possibly in addition to) a console that may or may not be present. Or send the messages to the Shell window, but marked somehow as internal. The warnings hook might be used after importing non-Idle modules but before importing Idle modules, so startup is not bogged down on debug builds by DeprecationWarnings from non-Idle modules To be a good citizen for testing, all custom hooks should be undone before the PyShell import finishes and before PyShell.main exits (same for run.py). -- messages: 191966 nosy: ned.deily, roger.serwy, terry.reedy priority: normal severity: normal status: open title: Idle: stop depending on console output type: behavior versions: Python 2.7, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18318 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18319] gettext() cannot find translations with plural forms
New submission from Jakub Wilk:
gettext() cannot find translations for messages that have plural forms. I would
expect that gettext(s) is equivalent to ngettext(s, s, 1) for such messages, as
it is implemented in GNU gettext.
import gettext
with open('test.mo', 'rb') as mo: trans = gettext.GNUTranslations(mo)
...
trans.ngettext(egg, eggs, 1)
'Ei'
trans.gettext(egg)
'egg'
--
components: Library (Lib)
files: test.mo
messages: 191967
nosy: jwilk
priority: normal
severity: normal
status: open
title: gettext() cannot find translations with plural forms
Added file: http://bugs.python.org/file30717/test.mo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18319
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18317] gettext: DoS via crafted Plural-Forms
Christian Heimes added the comment: Thanks, can you please provide the PO file, too? Or did you construct the MO file manually? -- nosy: +christian.heimes stage: - test needed versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18317 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18317] gettext: DoS via crafted Plural-Forms
Changes by Christian Heimes li...@cheimes.de: -- nosy: +loewis, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18317 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18317] gettext: DoS via crafted Plural-Forms
Christian Heimes added the comment: Ah, I see what you are doing. Nice catch! Plural-Forms: nplurals=0; plural=42**42**42; The plural form gets parsed by gettext.c2py() and eventually turned into a lambda that executes int(42**42**42). Perhaps a custom AST visitor could be used to filter out dangerous ops and limit the amount of ops to a sane amount? -- nosy: +barry -loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18317 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16487] Allow ssl certificates to be specified from memory rather than files.
Kristján Valur Jónsson added the comment: Okay, I have updated the patch as suggested. string mode means PEM encoding, binary mode DER encoding. Note that DER encoding is more limited, there is no way to concatentate private keys and certificates into one file (the PEM decoder searches the file until it finds the proper data it is looking for, certificate or private key). Also, the unittests don't test for DER encoded private key, because there is no way to generate them currently. The conversion functions in ssl only cope with certificates. Although adding them, changing them would be trivial. These functions should also probably know how to split a PEM file into sections so that they can be individually converted. -- Added file: http://bugs.python.org/file30718/ssl2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16487 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16113] Add SHA-3 (Keccak) support
Aaron Gallagher added the comment: https://pypi.python.org/pypi/cykeccak/ is what I've written to do this, for reference. Honestly I hope that the Keccak sponge is directly exposed in openssl (or any other SHA-3 implementation) because of its utility beyond SHA-3. If the source of some other implementation is going to be bundled with python anyway, it shouldn't be difficult to expose the sponge bits. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16113 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16468] argparse only supports iterable choices
Changes by paul j3 ajipa...@gmail.com: -- nosy: +paul.j3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16468 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18317] gettext: DoS via crafted Plural-Forms
Benjamin Peterson added the comment: Why do we have support for untrusted MO files? -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18317 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9938] Documentation for argparse interactive use
Andrew Berg added the comment: What is the status of this? If the patch looks good, then will it be pushed into 3.4? -- nosy: +aberg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9938 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9938] Documentation for argparse interactive use
R. David Murray added the comment: It's great that this patch was provided. Xuanji, can you submit a contributor agreement, please? The patch is missing an update to the documentation. (Really the patch should have been in a separate issue, as requested, since this one is about improving the documentation for the existing released versions. I guess we'll have to open a new issue for updating the docs in the existing versions). -- nosy: +r.david.murray stage: - needs patch versions: +Python 3.4 -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9938 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9938] Documentation for argparse interactive use
Andrew Berg added the comment: The patch doesn't work for 3.3 (I think it's just because the line numbers are different), but looking over what the patch does, it looks like parse_known_args will return a value for args if there is an unrecognized argument, which will cause parse_args to call error() (it should raise ArgumentError instead). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9938 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18081] test_logging failure in WarningsTest on buildbots
Terry J. Reedy added the comment: Improved 3.3 patch with tests incorporates Vinay's capture_warnings function to uncapture at end of import and main exit. I plan to apply after checking other versions and close this issue. -- Added file: http://bugs.python.org/file30719/issue18081-warn3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18081 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
