Re: Huh? No way to markup announcements here?
On 18/04/2015 11:24, edream...@gmail.com wrote: Many google groups support markdown or other markup. I see no mention of markup here: https://www.python.org/community/clpya-guidelines.txt/ Is there any way to format announcements? If so, how. If not, why not? Because this is not, primarily, a Google Group. Depending on your perspective it's either a Usenet group (comp.lang.python) or a mailing list (python-list). Services such as Google Groups, gmane or various web-based portals are interacting with one or other of those (last time I looked: GG was using nntp and gmane the mailing list). Both of those services -- Usenet Mailing list -- are traditionally plain text. One could certainly make a case for the uniquity and helpfulness of standard HTML markup, but I'm afraid that's unlikely to cut any ice in the face of a long-established and usually useful convention. Obviously you could use some established text markup such as ReST or markdown which is quite readable in plain text but which *could* be rendered to HTML by a suitable reader. TJG -- https://mail.python.org/mailman/listinfo/python-list
[issue5784] raw deflate format and zlib module
A.M. Kuchling added the comment: Here's a short patch that expands the discussion of wbits, and duplicates it under both the compressobj() and decompress() methods. Should I avoid the duplication and just have a reference? -- nosy: +akuchling Added file: http://bugs.python.org/file39102/patch-5784.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5784 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
levkivskyi added the comment: I would like to add that since the introduction of asyncio module that heavily uses yield from syntax, binding of yield inside comprehensions/generator expressions could lead to unexpected results/confusing behavior. See for example this question on SO: http://stackoverflow.com/questions/29334054/why-am-i-getting-different-results-when-using-a-list-comprehension-with-coroutin -- nosy: +levkivskyi ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10544 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5784] raw deflate format and zlib module
Martin Panter added the comment: Looks good in general (apart from one grammar comment). It might be best to only include one copy, and reference the others. There are actually three places “wbits” is allowed that I can see: * compressobj() * decompress() * decompressobj() Maybe just pointing from decompress() and decompressobj() back to the compressobj() description would be good enough. Unless if you know if wbits=0 is also accepted or not for decompression. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5784 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23993] Use surrogateescape error handler by default in open() if the locale is C
STINNER Victor added the comment: I am -1 on this. (Or may be more). What's the rationale? See the issue #19977. In many cases you get the C locale by mistake. For example, by setting the LANG environment variable to an empty string to run a program in english (whereas LC_MESSAGES is the appropriate variable). For deamons, in many cases you get the C locale and it's hard to configure all systems to run the daemon with the user locale. I read that systemd runs daemons with the user locale, but I'm not sure. The idea is to reduce the pain caused by this locale. When porting an application from Python 2 to Python 3, it's annoying to start to get unicode errors everywhere. This issue starts to make Python 3 more convinient. I could see using utf-8 by default if the locale is C, This has been proposed many times, but I'm opposed to that. Python must be interoperable with other programs, and other programs use the locale encoding. For example, you get the ASCII locale encoding when the LC_CTYPE is the POSIX locale (C). If Python writes UTF-8, other applications will be unable to decode UTF-8 data. Maybe I'm wrong and you should continue to investigate this option. This issue is very specific to OS data: environment variables, filenames, command line arguments, standard streams (stdin, stdout, stderr). You may do other choices for other kind of data unrelated to the locale encoding. For example, JSON must use UTF-8, it's well defined. XML announces its encoding. etc. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23993 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: This is exactly analogous to what you are seeing with __call__ and callable(). Your example is incorrect, __next__ is what makes an object iterable but not what makes an object have an iterator (what __iter__ does). This correctly characterises the issue: class NonIter: ... pass ... iter(NonIter()) Traceback (most recent call last): File stdin, line 1, in module TypeError: 'NonIter' object is not iterable class DynamicNonIter: ... has_iter = False ... ... @property ... def __iter__(self): ... if self.has_iter: ... from functools import partial ... return partial(iter, [1, 2, 3]) ... else: ... raise AttributeError(Not really ...) ... dni = DynamicNonIter() iter(dni) Traceback (most recent call last): File stdin, line 1, in module TypeError: 'DynamicNonIter' object is not iterable dni.has_iter = True iter(dni) list_iterator object at 0x0362FF60 Now, if this is possible for `iter`, why shouldn't it be possible for `callable`? I'm not opposed to writing a PEP but the issue with `callable` is the only one I'm aware of, and this seems too small in scope anyway. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17475] Better doc on using python-gdb.py
Carol Willing added the comment: The current devguide on gdb (https://docs.python.org/devguide/gdb.html?highlight=gdb) satisfies this issue. I am marking this languishing issue as a duplicate and closing it. -- nosy: +willingc resolution: - duplicate stage: patch review - resolved ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17475 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20962] Rather modest chunk size in gzip.GzipFile
Martin Panter added the comment: The gzip (as well as LZMA and bzip) modules should now use buffer and chunk sizes of 8 KiB (= io.DEFAULT_BUFFER_SIZE) for most read() and seek() type operations. I have a patch that adds a buffer_size parameter to the three compression modules if anyone is interested. It may need a bit work, e.g. adding the parameter to open(), mimicking the built-in open() function when buffer_size=0, etc. I did a quick test of seeking 100 MB into a gzip file, using the original Python 3.4.3 module, the current code that uses 8 KiB chunk sizes, and then my patched code with various chunk sizes. It looks like 8 KiB is significantly better than the previous code. My tests are peaking at about 64 KiB, but I guess that depends on the computer (cache etc). Anyway, 8 KiB seems like a good compromise without hogging all the fast memory cache or whatever, so I suggest we close this bug. Command line for timing looked like: python -m timeit -s 'import gzip' \ 'gzip.GzipFile(100M.gz, buffer_size=8192).seek(int(100e6))' Python 3.4.3: 10 loops, best of 3: 2.36 sec per loop Currently (8 KiB chunking): 10 loops, best of 3: 693 msec per loop buffer_size=1024: 10 loops, best of 3: 2.46 sec per loop buffer_size=8192: 10 loops, best of 3: 677 msec per loop buffer_size=16 * 1024: 10 loops, best of 3: 502 msec per loop buffer_size=int(60e3): 10 loops, best of 3: 400 msec per loop buffer_size=64 * 1024: 10 loops, best of 3: 398 msec per loop buffer_size=int(80e3): 10 loops, best of 3: 406 msec per loop buffer_size=16 * 8192: 10 loops, best of 3: 469 msec per loop -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20962 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23993] Use surrogateescape error handler by default in open() if the locale is C
R. David Murray added the comment: I am -1 on this. (Or may be more). What's the rationale? I could see using utf-8 by default if the locale is C, but I don't think we want to encourage going back to a world where people don't pay attention to the encoding of their data. A more productive approach to solving the problem that I think you are trying to solve here would be to work on including chardet in the standard library, something that was brought up, and seemed to receive positive reception (or at least not negative), during the Requests segment of the PyCon language summit. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23993 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23725] update tempfile docs to say that TemporaryFile is secure
Changes by Zbyszek Jędrzejewski-Szmek zbys...@in.waw.pl: Added file: http://bugs.python.org/file39104/tempfile_docs.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Huh? No way to markup announcements here?
On 2015-04-18, edream...@gmail.com edream...@gmail.com wrote: Many google groups support markdown or other markup. I see no mention of markup here: https://www.python.org/community/clpya-guidelines.txt/ Is there any way to format announcements? If so, how. If not, why not? Because this is not a google group, it is a Usenet group, and Usenet groups are plaintext-only. -- https://mail.python.org/mailman/listinfo/python-list
[issue23536] Add explicit information on config file format not supporting filters
Roundup Robot added the comment: New changeset df28044b7e14 by Vinay Sajip in branch '2.7': Issue #23536: Clarified scope of fileConfig()'s API. https://hg.python.org/cpython/rev/df28044b7e14 New changeset 968c086bf6cc by Vinay Sajip in branch '3.4': Issue #23536: Clarified scope of fileConfig()'s API. https://hg.python.org/cpython/rev/968c086bf6cc New changeset 439517000aa2 by Vinay Sajip in branch 'default': Closes #23536: Clarified scope of fileConfig()'s API. https://hg.python.org/cpython/rev/439517000aa2 -- nosy: +python-dev resolution: - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23536 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5784] raw deflate format and zlib module
Changes by A.M. Kuchling a...@amk.ca: -- stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5784 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Calling back into Python from llvmlite-JITed code
An article from Eli Bendersky that I found interesting, maybe the same applies to you. http://eli.thegreenplace.net/2015/calling-back-into-python-from-llvmlite-jited-code/ -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
[issue23993] Use surrogateescape error handler by default in open() if the LC_CTYPE locale is C at startup
Changes by STINNER Victor victor.stin...@gmail.com: -- title: Use surrogateescape error handler by default in open() if the locale is C - Use surrogateescape error handler by default in open() if the LC_CTYPE locale is C at startup ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23993 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16574] clarify policy on updates to final peps
Carol Willing added the comment: This patch should close this languishing devguide issue. This patch adds wording suggested by Terry Reedy re: pep documentation reference to section 7.4.5 Inline markup (https://docs.python.org/devguide/documenting.html#id3). The devguide covers the pep process and PEP 1 in section 20.1.2 (https://docs.python.org/devguide/langchanges.html?highlight=pep#pep-process). -- keywords: +patch nosy: +willingc stage: - patch review Added file: http://bugs.python.org/file39101/iss16574.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16574 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17703] Trashcan mechanism segfault during interpreter finalization in Python 2.7.4
Daniel added the comment:
Guillaume already mentioned this, its still causing a Fatal Error. To fix this
PyThreadState_GET() in Py_TRASHCAN_SAFE_BEGIN must be replaced with
_PyThreadState_Current
#define Py_TRASHCAN_SAFE_BEGIN(op) \
do { \
PyThreadState *_tstate = _PyThreadState_Current; \
--
nosy: +m_python
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17703
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Importing/migrating Mailman mbox files into Google Groups?
On Fri, Apr 17, 2015 at 7:33 PM, Cameron Simpson c...@zip.com.au wrote: However, before you get very excited see if people can get messages back out of the archive. A major annoyance for me with GGroups versus mailman is that if I join a group I cannot download the historical archive. (This is a standard step for me when I join a mailing list. I hear mailman 3 might be tossing this facility; I am unimpressed.) I'll clarify briefly. The archives are from a now-defunct mailing list which accumulated about 190k posts during its nearly ten-year life. The only interface to the archives is a rather feeble search interface. There is no way to just read through the archives in chronological fashion. I know Google Groups isn't very popular here, but trust me, it would provide a much better interface to these archives than the current search interface. I will obviously verify that the messages can be read through GG before dumping all of them into this archive. Skip -- https://mail.python.org/mailman/listinfo/python-list
[issue23993] Use surrogateescape error handler by default in open() if the LC_CTYPE locale is C at startup
STINNER Victor added the comment: For a more concrete use case, see the makefile problem in Mercurial wiki page: http://mercurial.selenic.com/wiki/EncodingStrategy#The_.22makefile_problem.22 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23993 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Huh? No way to markup announcements here?
Many google groups support markdown or other markup. I see no mention of markup here: https://www.python.org/community/clpya-guidelines.txt/ Is there any way to format announcements? If so, how. If not, why not? Edward -- https://mail.python.org/mailman/listinfo/python-list
[issue23993] Use surrogateescape error handler by default in open() if the locale is C
STINNER Victor added the comment: Updated and better patch: version 2. - revert changes on fileutils.c: it's not useful to check for check_force_ascii(), because this function is more strict than checking of the LC_CTYPE is C - fix _pyio.py: add sys import - complete the documentation - tests pass -- Added file: http://bugs.python.org/file39103/default_error_handler-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23993 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23725] update tempfile docs to say that TemporaryFile is secure
Zbyszek Jędrzejewski-Szmek added the comment: Replying to review here... I get 500 server error in the patch review reply dialogue :( On 2015/04/15 02:40:14, r.david.murray wrote: http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst File Doc/library/tempfile.rst (left): http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#oldcode55 Doc/library/tempfile.rst:55: :keyword:`with` statement, just like a normal file. Why did you remove this statement? It is redundant. The fact that this can be used as CM is already mentioned in the introduction and in the description of TemporaryFile. http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst File Doc/library/tempfile.rst (right): http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode25 Doc/library/tempfile.rst:25: The need to use the insecure :func:`mktemp` function is eliminated. How about we get even more radical. Let's eliminate the mention of mktemp from the documentation, except for a Deprecated Functions section at the end, where we explain that it is deprecated because it is insecure and anything you could do with it you can do with the un-deprecated functions. Agreed. I'll submit a new version which removes all the historical notes and adds a Deprecated section at the end for tempdir and mktemp. http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode27 Doc/library/tempfile.rst:27: instead a string of six random characters is used. Let's likewise eliminate the mention of the process id, and just leave the explanation that six random characters are used. OK. http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode31 Doc/library/tempfile.rst:31: directories. It is no longer necessary to use the global *tempdir* variable. The global tempdir variable can likewise be moved to the deprecated section and removed from mention here. OK. http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode42 Doc/library/tempfile.rst:42: collected). Under Unix, the directory entry for the file is either not created at all or removed or is removed OK. http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode247 Doc/library/tempfile.rst:247: There should be another blank line here. v5: - relegate `tempdir` and `mktemp` descriptions to 'Deprecated functions and variables' section at the end. This requires moving some descriptions around. - add missing is pointed out in review - add missing 's' -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: On Sat, Apr 18, 2015 at 7:23 PM, Ethan Furman rep...@bugs.python.org wrote: class GenericProxy: def __init__(self, proxied): self.proxied = proxied # in case proxied is an __iter__ iterator @property def __iter__(self): if not hasattr(self.proxied, '__iter__'): raise AttributeError else: return self @property def __next__(self): if not hasattr(self.proxied, '__next__'): raise AttributeError else: return next(self.proxied) Unfortunately your implementation is incorrect as you forgot to that the property needs to return a function. This is a correct implementation that works as expected (in the sense that *iter does in fact honor the descriptor protocol)*: class GenericProxy: def __init__(self, proxied): self.proxied = proxied # in case proxied is an __iter__ iterator @property def __iter__(self): if not hasattr(self.proxied, '__iter__'): raise AttributeError else: return *lambda:* self @property def __next__(self): if not hasattr(self.proxied, '__next__'): raise AttributeError else: return *lambda: *next(self.proxied) The iter machinery doesn't grab values and call them, you've misinterpreted the error. Thanks, -- Ionel Cristian Mărieș, http://blog.ionelmc.ro -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23961] IDLE autocomplete window does not automatically close when selection is made
Al Sweigart added the comment: I should clarify: I'm referring to the Show Completion feature. The repro steps are (on Windows 7 64-bit, Python 3.5) 1. Type pri 2. Press Ctrl+Space or click Edit Show Completions. The autocomplete window appears. 3. Press Tab. The text updates from pri to print 4. However, the autocomplete window is still there. 5. Pressing space or ( will then cause the autocomplete window to disappear. This is distinct from issue 15786, but close enough that I'll close this bug and add this comment to it. Thanks for the input! -- resolution: - duplicate ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23961 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: HELP! How to return the returned value from a threaded function
D. Xenakis gouzouna...@hotmail.com writes: Maybe this is pretty simple but seems I am stuck... thread_maker() == HelloWorld! This sounds like homework... what have you tried, and what happened? Have you looked at the docs of the threading module? -- https://mail.python.org/mailman/listinfo/python-list
[issue23496] Steps for Android Native Build of Python 3.4.2
Cyd Haselton added the comment: Do you have the time/means to create a quick patch for that? I ask because even a simple flip like that becomes a major pain when working with nano on a tablet. If not, I'll start on it. Just thought Id ask -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23496 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: HELP! How to return the returned value from a threaded function
This sounds like homework... what have you tried, and what happened? heheh naaah no cheating here. I just provided the example this way to make as clear as possible what I want to do. Return the returned value from a threaded function. apparently this does not work as I hoped: return Thread(target=message_function).start() Have you looked at the docs of the threading module? Lost in there -- https://mail.python.org/mailman/listinfo/python-list
[issue23995] msvcrt could not be imported
New submission from petrikas: Python cannot access msvcrt's putwch() when using manage.py syncdb To reproduce: 1. Call manage.py syncdb and try to create a new superuser 2. It crashes after inputting email (or before asking for the password) Reproducible with 3.5a3, seems to be a regression from 3.4.3. Downgrading fixed the issue -- components: Library (Lib) messages: 241438 nosy: petrikas priority: normal severity: normal status: open title: msvcrt could not be imported type: crash versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23995] msvcrt could not be imported
petrikas added the comment: Edit: I am using a windows 8.1 system and django 1.8 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23989] Add recommendation to use requests to the documentation, per summit
Gregory P. Smith added the comment: nice and simple. that wording looks good to me. -- nosy: +gregory.p.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23989 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values
Ned Deily added the comment: Current source releases of Python do not specify which version of Tk they should be run with; that is largely up to the distributors of Python (including python.org binary installers for Windows and OS X) and the conventions of the platform the instances are running on. There are versions of current Python 3.4.x and Python 2.7.x running on supported platforms (like OS X) with various flavors of Tk 8.6, 8.5, and even 8.4. So Python documentation has to be careful to avoid making assumptions about Tk version-specific features. FWIW, a link to Tk 8.6 differences is provided on the Tcl/Tk 8.6 release page (http://www.tcl.tk/software/tcltk/8.6.html) - Changes in Tcl/Tk 8.6 (http://wiki.tcl.tk/21276). -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23982 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23725] update tempfile docs to say that TemporaryFile is secure
R. David Murray added the comment: Made one minor suggestion in review comments (related to that deleted line). Otherwise this looks good to me, thanks. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ethan Furman added the comment: Perhaps callable() should be in the inspect module? ;) Speaking of which, how do all the is... functions there work with this descriptor implementation? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23995] msvcrt could not be imported
R. David Murray added the comment: Can you reproduce this without involving Django? That would make it more likely that someone will have time to take a look at it. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
R. David Murray added the comment: They use isinstance, except for a couple that also check co_flags, and the ones that check if the object is a descriptor. I haven't thought this through fully, but I think this means that in general the descriptor protocol has been invoked or not by the caller of inspect before inspect checks the object. There is no 'callable' type in python, so the closest analog in the inspect module to 'callable' are the functions that look for __get__ and __set__ methods on descriptors. If one of *those* is a descriptor, my head will start hurting :). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: Turns out I've replied through email, and code got mangled. This is the correct version: class GenericProxy: def __init__(self, proxied): self.proxied = proxied @property def __iter__(self): if not hasattr(self.proxied, '__iter__'): raise AttributeError else: return lambda: self @property def __next__(self): if not hasattr(self.proxied, '__next__'): raise AttributeError else: return lambda: next(self.proxied) Note the lambdas. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23496] Steps for Android Native Build of Python 3.4.2
Ryan Gonzalez added the comment:
Ok...try going to Python/pylifecycle.c and changing lines 220-230 from:
#elif defined(HAVE_LANGINFO_H) defined(CODESET)
char* codeset = nl_langinfo(CODESET);
if (!codeset || codeset[0] == '\0') {
PyErr_SetString(PyExc_ValueError, CODESET is not set or empty);
return NULL;
}
return get_codec_name(codeset);
#elif defined(__ANDROID__)
char* m = malloc(6);
strcpy(m, ascii);
return m;
to:
#elif defined(__ANDROID__)
char* m = malloc(6);
strcpy(m, ascii);
return m;
#elif defined(HAVE_LANGINFO_H) defined(CODESET)
char* codeset = nl_langinfo(CODESET);
if (!codeset || codeset[0] == '\0') {
PyErr_SetString(PyExc_ValueError, CODESET is not set or empty);
return NULL;
}
return get_codec_name(codeset);
I just swapped the `elif`'s around.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23496
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
HELP! How to return the returned value from a threaded function
Maybe this is pretty simple but seems I am stuck... def message_function(): return HelloWorld! def thread_maker(): call message_function() using a new thread and return it's HelloWorld! pass Could someone please complete above script so that: thread_maker() == HelloWorld! Please import the library you suggest too. I tried threading but I could not make it work. THX! -- https://mail.python.org/mailman/listinfo/python-list
[issue23990] Callable builtin doesn't respect descriptors
Ethan Furman added the comment: I am happy to be proven wrong. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: generator/coroutine terminology
In article 551e2cfd$0$11123$c3e8...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Wednesday 01 April 2015 00:18, Albert van der Horst wrote: In article 55062bda$0$12998$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: The biggest difference is syntactic. Here's an iterator which returns a never-ending sequence of squared numbers 1, 4, 9, 16, ... class Squares: def __init__(self): self.i = 0 def __next__(self): self.i += 1 return self.i**2 def __iter__(self): return self You should give an example of usage. As a newby I'm not up to figuring out the specification from source for something built of the mysterious __ internal thingies. (I did experiment with Squares interactively. But I didn't get further than creating a Squares object.) Ah, sorry about that! Usage is: it = Squares() # create an iterator print(next(it)) # print the first value x = next(it) # extract the second while x 100: print(x) x = next(it) Beware of doing this: for x in Squares(): print(x) since Squares is an *infinite* generator, it will continue for ever if you let it. Fortunately you can hit Ctrl-C to interrupt the for loop at any point. In Python 2, you will need to rename __next__ to just next without the double-leading-and-trailing underscores. Here's the same thing written as a generator: def squares(): i = 1 while True: yield i**2 i += 1 And for this one: it = squares() # create the iterator print(next(it)) # print the first value x = next(it) # extract the second while x 100: print(x) x = next(it) Usage is pretty much exactly the same. Thanks, I get it now. next and yield are more or less switching between coroutines. -- Steve -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spearc.xs4all.nl =n http://home.hccnet.nl/a.w.m.van.der.horst -- https://mail.python.org/mailman/listinfo/python-list
[issue23990] Callable builtin doesn't respect descriptors
Christian Heimes added the comment:
On 2015-04-18 19:43, Ionel Cristian Mărieș wrote:
Ionel Cristian Mărieș added the comment:
On Sat, Apr 18, 2015 at 8:35 PM, Christian Heimes rep...@bugs.python.org
wrote:
You also haven't shown that this behavior violates the documentation and
language spec.
How can I show it violates the spec when there's not such thing? :-)
AFAIK, `callable` is not specified in any PEP. Please give some references
when you make such statements.
The language specs is made up from two things:
1) the CPython reference implemention
2) the documentation of the CPython reference implementation
3) accepted and implemented PEPs
If 3) doesn't exist and 2) doesn't contain any point that contradicts
1), then 1) and 2) agree on an implementation and therefore it is
informally specified. The fact that PyPy and Jython show the same
behavior, adds additional weight to 1), too.
callable() has been implemented like that since the introduction of new
style classes, too.
$ hg checkout v2.2
$ grep -A20 ^PyCallable_Check Objects/object.c
PyCallable_Check(PyObject *x)
{
if (x == NULL)
return 0;
if (PyInstance_Check(x)) {
PyObject *call = PyObject_GetAttrString(x, __call__);
if (call == NULL) {
PyErr_Clear();
return 0;
}
/* Could test recursively but don't, for fear of endless
recursion if some joker sets self.__call__ = self */
Py_DECREF(call);
return 1;
}
else {
return x-ob_type-tp_call != NULL;
}
}
You really have to make a *very* good case with a PEP in order to get
everybody to switch to a different behavior!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23990
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23964] Update README documentation for IDLE tests.
Al Sweigart added the comment: I'll add a note about running the human-mediated tests to section 0. Running python -m test.test_idle for 64-bit 3.4.3 on Windows 7 works fine for me (Ran 142 tests in 0.605s OK) I'll take out the indented code. You make a good point about copy/paste. I've added section 4 on human-mediated tests. I'd like to take a crack at improving the documentation a bit in htest.py before figuring out what to add to section 4. This can be addressed in a later patch. -- Added file: http://bugs.python.org/file39107/idle_test_readme.2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23964 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23496] Steps for Android Native Build of Python 3.4.2
Ryan Gonzalez added the comment:
Here:
diff -r 38f5b3beeb2a Python/pylifecycle.c
--- a/Python/pylifecycle.c Thu Mar 19 15:16:03 2015 -0500
+++ b/Python/pylifecycle.c Sat Apr 18 13:07:36 2015 -0500
@@ -217,6 +217,10 @@
char codepage[100];
PyOS_snprintf(codepage, sizeof(codepage), cp%d, GetACP());
return get_codec_name(codepage);
+#elif defined(__ANDROID__)
+char* m = malloc(6);
+strcpy(m, ascii);
+return m;
#elif defined(HAVE_LANGINFO_H) defined(CODESET)
char* codeset = nl_langinfo(CODESET);
if (!codeset || codeset[0] == '\0') {
@@ -224,10 +228,6 @@
return NULL;
}
return get_codec_name(codeset);
-#elif defined(__ANDROID__)
-char* m = malloc(6);
-strcpy(m, ascii);
-return m;
#else
PyErr_SetNone(PyExc_NotImplementedError);
return NULL;
On Sat, Apr 18, 2015 at 12:39 PM, Cyd Haselton rep...@bugs.python.org
wrote:
Cyd Haselton added the comment:
Do you have the time/means to create a quick patch for that?
I ask because even a simple flip like that becomes a major pain when
working with nano on a tablet.
If not, I'll start on it. Just thought Id ask
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23496
___
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23496
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
R. David Murray added the comment: I understand Ionel's point, and it is indeed 'callable' that is the outlier here. It only looks for the *existence* of the attribute, rather than actually retrieving it through the descriptor protocol (and therefore getting the AttributeError from the property). Protocols like iter, on the other hand, actually use the attribute, and therefore do access it via the descriptor protocol, and properties therefore act like one would naively expect them to. That doesn't mean we should definitely change callable, but it does mean the idea isn't obviously wrong. IMO it is indeed callable that has the surprising behavior here. (Note: I did not think that at first, but I do after reading the iter discussion. (NB: in general, __iter__ should *not* return self; that's a bug waiting to happen.)) But, callable is also...not exactly Pythonic at its core, as evidenced by Guido's desire to get rid of it. So the fact that it is in some sense buggy or at least surprising is perhaps something that we just live with because of that. IMO, code that depends on a __call__ property is a bit suspect anyway. Something should be callable or not, not conditionally callable. If a program wants things to be conditionally callable, the program can establish its own protocol for that. (The same applies to __iter__, but there's no reason to intentionally break the fact that it does work, since it just falls out of how the language works.) So I guess my feeling is...callable is buggy, but callable is a buggy API :) So I'm 0 on this issue (not even +0 or -0). -- nosy: +r.david.murray resolution: - not a bug stage: test needed - resolved status: open - closed type: enhancement - behavior versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4 -Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23994] argparse fails to detect program name when there is a slash at the end of the program's path
Gregory P. Smith added the comment: I think this was just overlooked when implementing argparse. Most code out there is likely to get the executable name using: os.path.basename(sys.argv[0]) Which is going to do exactly what you are seeing here when sys.argv[0] ends with a /. feel free to submit a patch. perhaps as simple as this? os.path.basename(sys.argv[0].rstrip(os.path.sep)) But I'd expect a bunch of other code out there to have the same problem. -- nosy: +gregory.p.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23994 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23955] Add python.ini file for embedded/applocal installs
Steve Dower added the comment: I could reuse the venv config file but it would need a new property to forcibly use the 'home' value regardless of whether '$home\Lib\os.py' exists (in case the stdlib is zipped) and to make it relative to the file's path rather than the user's current directory. How about adding an 'applocal=True' property to pyvenv.cfg that basically implies -I, PYTHONHOME=os.dirname(pyvenv_cfg), and skips the registry lookup on Windows completely (which there's currently no way to achieve)? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23955 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5784] raw deflate format and zlib module
A.M. Kuchling added the comment: Thanks! Here's an updated version with some more rewriting -- the list is now in only one place and is linked-to from the decompression documentation. -- Added file: http://bugs.python.org/file39105/patch-5784.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5784 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23955] Add python.ini file for embedded/applocal installs
Steve Dower added the comment: Arguably we should be making 'home' in pyvenv.cfg relative to the pyvenv.cfg file's directory anyway... AFAIK it's always generated as an absolute path, but I see no good reason to prevent people from manually configuring a relative path here. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23955 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23984] Documentation error: Descriptors
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- assignee: docs@python - rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23984 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Huh? No way to markup announcements here?
On Sat, 18 Apr 2015 11:36:34 +0100, Tim Golden m...@timgolden.me.uk wrote: On 18/04/2015 11:24, edream...@gmail.com wrote: [snip] Is there any way to format announcements? If so, how. If not, why not? [snip] Both of those services -- Usenet Mailing list -- are traditionally plain text. One could certainly make a case for the uniquity and helpfulness of standard HTML markup, but I'm afraid that's unlikely to cut any ice in the face of a long-established and usually useful convention. Obviously you could use some established text markup such as ReST or markdown which is quite readable in plain text but which *could* be rendered to HTML by a suitable reader. If I might, for a moment, play the role of the Tiresome Geezer, let me observe, as a Usenet fan since the 1980's, that Usenet has been enormously useful, convenient, and reliable. Browsers and HTML are great, and I use them far more than Usenet; but you always need to upgrade to some Even Newer Adobe Flash Player, and there are five new Urgent Security Releases every month, and I can't concentrate while that damn advertisement is flashing, and if you enable Javascript the Russian mafia will use your computer to spam your neighbors but if you don't then all the cool sites come up blank. Usenet, in contrast, just keeps on working. -- To email me, substitute nowhere-runbox, invalid-com. -- https://mail.python.org/mailman/listinfo/python-list
[issue15786] IDLE code completion window can hang or misbehave with mouse
Al Sweigart added the comment: Additionally, pressing tab after the autocomplete window has appeared should not just update the text but also close the autocomplete window. The repro steps are (on Windows 7 64-bit, Python 3.5): 1. Type pri 2. Press Ctrl+Space or click Edit Show Completions. The autocomplete window appears. 3. Press Tab. The text updates from pri to print 4. However, the autocomplete window is still there. 5. Pressing space or ( will then cause the autocomplete window to disappear. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15786 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Christian Heimes added the comment: All major Python implementation have a mutual agreement that callable() just checks for a __call__ member on the type. You also haven't shown that this behavior violates the documentation and language spec. The check for existence of __call__ on the type is well in the range of expected behavior. I as well as other core devs had the same gut feeling. Finally your suggestion makes the implementation of callable() more complex and much, much slower. Right now and for more than a decade it is a simple, fast and straight forward code path for new style classes. It just requires two pointer derefs and one comparison to NULL. I'm still -1 on the change. If you want to go forth with your request then you must write a PEP and convince all implementors of Python implementations to change the current way callable() and other protocols like iter work. $ python2.7 Python 2.7.8 (default, Nov 10 2014, 08:19:18) [GCC 4.9.2 20141101 (Red Hat 4.9.2-1)] on linux2 Type help, copyright, credits or license for more information. class A(object): ... @property ... def __call__(self): ... raise AttributeError ... a = A() print(callable(a)) True a() Traceback (most recent call last): File stdin, line 1, in module File stdin, line 4, in __call__ AttributeError $ jython Jython 2.7b3+ (, Nov 3 2014, 11:02:14) [OpenJDK 64-Bit Server VM (Oracle Corporation)] on java1.8.0_40 Type help, copyright, credits or license for more information. class A(object): ... @property ... def __call__(self): ... raise AttributeError ... a = A() print(callable(a)) True a() Traceback (most recent call last): File stdin, line 1, in module File stdin, line 4, in __call__ AttributeError $ pypy Python 2.7.8 (a980ebb26592ed26706cd33a4e05eb45b5d3ea09, Sep 24 2014, 07:41:52) [PyPy 2.4.0 with GCC 4.9.1 20140912 (Red Hat 4.9.1-9)] on linux2 Type help, copyright, credits or license for more information. class A(object): @property def __call__(self): raise AttributeError a = A() print(callable(a)) True a() Traceback (most recent call last): File stdin, line 1, in module File stdin, line 4, in __call__ AttributeError -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23994] argparse fails to detect program name when there is a slash at the end of the program's path
New submission from Mert Bora Alper: Sorry if the title is not descriptive enough. When I try to execute a program from a directory which contains an `__main__.py` file, argparse fails to detect programs name. For example: $ ls foo __main__.py $ python3 foo usage: foo [-h] [-c COUNT] length foo: error: the following arguments are required: length $ python3 foo/ usage: [-h] [-c COUNT] length : error: the following arguments are required: length argparse.__version__ '1.1' I followed same steps using Python 2.7.6 and got same result. It will probably be same on other versions too. Same result can also be obtained when using zip files instead of directories. I don't know if this is a bug since I don't know if I do something wrong or is this a design decision or not. Thank you, Bora -- components: Library (Lib) files: __main__.py messages: 241434 nosy: boramalper priority: normal severity: normal status: open title: argparse fails to detect program name when there is a slash at the end of the program's path type: behavior versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file39106/__main__.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23994 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Best search algorithm to find condition within a range
In article fd544688-5e9c-418e-9ca9-11b9bcb83...@googlegroups.com, jonas.thornv...@gmail.com wrote: Den tisdag 7 april 2015 kl. 16:30:15 UTC+2 skrev Denis McMahon: On Tue, 07 Apr 2015 09:29:59 -0400, Dave Angel wrote: On 04/07/2015 05:44 AM, jonas.thornv...@gmail.com wrote: I want todo faster baseconversion for very big bases like base 1 000 000, so instead of adding up digits i search it. How do you know the baseconversion is the bottleneck, if you haven't written any Python code yet? He doesn't. He doesn't comprehend that as far as a computer is concerned an integer has no specific 'base', it's only when presented in a form for humans to read that it gets base information added in the representation. He's making these and other similar errors in the javascript groups too. I suspect he's one of those people that spends his time thinking up elaborate solutions that he has no idea how to implement as a response to dreamt up non existent problems. -- Denis McMahon, denismfmcma...@gmail.com Bullshit declare two integers in any language one 7 and one 4 and then write x=7+4; if you find a programming language where that does not yield 11 tell me. Integers are internally assumed to be base 10 otherwise you could not calculate without giving the base. All operations on integers addition, subtraction, multiplication and division assume base 10. Fire up a lowlevel interpreter like Forth. (e.g. gforth) 7 CONSTANT A4 CONSTANT B A B + PAD ! PAD now contains the sum of A and B. Now inspect the actual computer memory: PAD 100 DUMP You will see the bytes, represented in base 16, but PAD just contains 11 PAD ? 11 OK In forth you can change the number base. That doesn't affect PAD but the output is different HEX PAD ? B OK DECIMAL Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spearc.xs4all.nl =n http://home.hccnet.nl/a.w.m.van.der.horst -- https://mail.python.org/mailman/listinfo/python-list
Re: generator/coroutine terminology
On Friday, March 13, 2015 at 5:36:35 PM UTC+8, Marko Rauhamaa wrote: Rustom Mody rustompm...@gmail.com: Nice demo of the same confusing terminology we are talking about. Why don't you just stick with the terminology of the language specification? I think your students are going to be more confused if you try to come up with something better. When I say expect generators to close I mean 'generator-instances' ie at runtime When you say expect both to close with return you are talking of program-texts ie the 'factory' [Or I am guilty of the same I am accusing python of] Your 'factory' is a: generator A function which returns an iterator. URL: https://docs.python.org/3/glossary.html Your 'generator-instance' is an: iterator An object representing a stream of data. URL: https://docs.python.org/3/glossary.html I don't think you should read much into what str(obj) returns. It's not much more than a random printable some CPython coder has cooked up in the heat of the moment. Marko Well, the functional that returns a function instance which can be used as an interator is also a function. Well, some might use terms in generics programming as described in the book by Gangs of 4. -- https://mail.python.org/mailman/listinfo/python-list
[issue23971] dict(list) and dict.fromkeys() doesn't account for 2/3 fill ratio
Gregory P. Smith added the comment: fwiw, as for 2.7 i personally don't think I would change its behavior around this at this point. make sure 3.5+ do something desirable. (my link to dictobject.c above is from 2.7) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23971 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23992] multiprocessing: MapResult shouldn't fail fast upon exception
Changes by Ned Deily n...@acm.org: -- nosy: +davin, sbt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23992 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23995] msvcrt could not be imported
eryksun added the comment: The new CRT used by 3.5 has a separate header, corecrt_wconio.h, for declarations shared by conio.h and wchar.h. Thus the _WCONIO_DEFINED macro is no longer defined, and consequently PC/msvcrtmodule.c skips defining getwch, getwche, putwch, and ungetwch. I guess this check was added to support DOS-based Windows 9x. NT-based Windows would always support wide-character console I/O. -- components: +Windows nosy: +eryksun, steve.dower, tim.golden, zach.ware ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ethan Furman added the comment:
Your example shows /having/ an iterator, while mine is /being/ an iterator.
A simple iterator:
# iterator protocol
class uc_iter():
def __init__(self, text):
self.text = text
self.index = 0
def __iter__(self):
return self
def __next__(self):
try:
result = self.text[self.index].upper()
except IndexError:
raise StopIteration
self.index += 1
return result
ucii = uc_iter('abc')
I believe your over-arching goal is a proxy class?
class GenericProxy:
def __init__(self, proxied):
self.proxied = proxied
# in case proxied is an __iter__ iterator
@property
def __iter__(self):
if not hasattr(self.proxied, '__iter__'):
raise AttributeError
else:
return self
@property
def __next__(self):
if not hasattr(self.proxied, '__next__'):
raise AttributeError
else:
return next(self.proxied)
and then two proxies to test -- a non-iterable and an iterable:
gp_ni = GenericProxy(object())
gp_ucii = GenericProxy(ucii)
and a quick harness:
try:
for _ in iter(gp_ni):
print(_)
except Exception as e:
print(e)
try:
for _ in iter(gp_ucii):
print(_)
except Exception as e:
print(e)
Note: the presence/absence of iter() makes no difference to the results below.
The non-iterable gives the correct error: 'GenericProxy' object is not iterable
But the iterable gives: 'GenericProxy' object is not callable
That error message is a result of the iter machinery grabbing the __next__
attribute and trying to call it, but property attributes are not callable.
In other words, iter() does not honor the descriptor protocol.
So now we have two: callable() and iter(). How many more are there?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23990
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: On Sat, Apr 18, 2015 at 8:35 PM, Christian Heimes rep...@bugs.python.org wrote: You also haven't shown that this behavior violates the documentation and language spec. How can I show it violates the spec when there's not such thing? :-) AFAIK, `callable` is not specified in any PEP. Please give some references when you make such statements. [...] write a PEP and convince all implementors of Python implementations to change the current way callable() and other protocols like iter work. `iter` works fine, as outlined above? Am I missing something? What other protocols do you have in mind, wrt honoring descriptors? Thanks, -- Ionel Cristian Mărieș, http://blog.ionelmc.ro -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23993] Use surrogateescape error handler by default in open() if the LC_CTYPE locale is C at startup
R. David Murray added the comment: Hmm. Upon reflection I guess I can see the validity of if you are using the C locale you or the OS are broken anyway, so we'll just pass the bytes through. I'm not entirely convinced this won't cause issues, but I suppose it might not cause any more issues that having things break due to the C locale does. It is, however, going to return us to the days when a program that works fine most of the time suddenly blows up in the face of non-ascii data, and that's my biggest concern. I'd certainly be fine with it if it wasn't the default (that is, programs who need this have to opt in to it). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23993 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23971] dict(list) and dict.fromkeys() doesn't account for 2/3 fill ratio
Gregory P. Smith added the comment: Won't we always consume the memory thanks to a memset(newtable, 0, ...) https://hg.python.org/cpython/file/df28044b7e14/Objects/dictobject.c#l654 ? (also, i'm not sure if Windows is allocates mapped pages on demand as posix systems tend to) -- nosy: +gregory.p.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23971 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23725] update tempfile docs to say that TemporaryFile is secure
R. David Murray added the comment: Oh, because of the O_TMPDIR bits, this patch is only applicable to 3.5, so I'm removing 3.4 from versions. I don't think it is worth it to make a version that would apply to 3.4, since it is not the case that the 3.4 docs are *wrong*. -- versions: -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Custom format a la datetime
Hello everybody. I'm writing a CLI program to do some search. It's an internal tool. I'd like to provide the option to my user to format the results as he/she'd like. Something similar to strftime on the datetime module. Example: from datetime import datetime d = datetime.utcnow() d.strftime(%Y-%m-%d) # '2015-04-18' d.strftime(%y-%m-%d) # '15-04-18' d.strftime(Today it's the %dth day in the %mth month of %Y) # 'Today it's the 18th day in the 04th month of 2015' # Don't pay attention to ordinals, just simple example. Now, an example of with my application. Suppose my app search cars: python search_cars.py -F Brand %B, model %m, year %Y # Brand Ford, model Focus, year 1996 python search_cars.py -F %B - %m (%y) # Ford - Focus (96) I'd provide my user with a table like: %B = Brand %m = Model %Y = Year format %y = Year format YY %s = Seller name ... etc... Thanks a lot for your help! -- https://mail.python.org/mailman/listinfo/python-list
[issue23990] Callable builtin doesn't respect descriptors
R. David Murray added the comment: Oops, I accidentally changed the bug status due to not refreshing before I posted. -- resolution: not a bug - stage: resolved - status: closed - open versions: +Python 3.5 -Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23496] Steps for Android Native Build of Python 3.4.2
Cyd Haselton added the comment: Ryan, Sorry...same problem. Segmentation fault generate-posix-vars failed make: *** [pybuilddir.txt] Error 1 /bld/python/cpython-master/cpython $ addr2line -C -f -e /lib/libpython3.5m.so.1.0 0008f42c _PyMem_RawStrdup /bld/python/cpython-master/cpython/Objects/obmalloc.c:358 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23496 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23984] Documentation error: Descriptors
Raymond Hettinger added the comment: In addition to being broken, the code is a crummy example that gives no hint of why one might want to use a staticmethod. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23984 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23997] unicodedata_UCD_lookup() has theoretical buffer overflow
New submission from Christian Heimes: Coverity has found a potential buffer overflow in the unicodedata module. The function call _getcode() which calls _cmpname(). _cmpname() copies data into fixed size buffer of length NAME_MAXLEN. Neither lookup() nor _getcode() limit name_length to NAME_MAXLEN. Therefore the buffer could theoretical overflow. In practice the buffer overflow can't be abused because Tools/unicode/makeunicodedata.py already limits max name length. I still like to fix the bug because it is a low hanging fruit. In most versions of Python the code already checks that name_length fits in INT_MAX. CID 1295028 (#1 of 1): Out-of-bounds access (OVERRUN) overrun-call: Overrunning callee's array of size 256 by passing argument (int)name_length (which evaluates to 2147483647) in call to _getcode -- files: unicode_name_maxlen.patch keywords: patch messages: 241461 nosy: benjamin.peterson, christian.heimes, ezio.melotti, haypo, lemburg, pitrou, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: unicodedata_UCD_lookup() has theoretical buffer overflow type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39109/unicode_name_maxlen.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23997 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23998] PyImport_ReInitLock() doesn't check for allocation error
New submission from Christian Heimes: _PyImport_ReInitLock() doesn't check the return value of PyThread_allocate_lock(). A failed lock allocation can either lead to a NULL pointer dereference or to race conditions caused by a missing import lock. As there is no way to recover from a failed lock allication I recommend to abort with a fatal error. CID 1295025 (#1 of 1): Dereference after null check (FORWARD_NULL) var_deref_model: Passing null pointer import_lock to PyThread_acquire_lock, which dereferences it. -- files: import_reinit_fatal.patch keywords: buildbot, easy, patch messages: 241462 nosy: christian.heimes priority: normal severity: normal stage: patch review status: open title: PyImport_ReInitLock() doesn't check for allocation error type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39110/import_reinit_fatal.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23998 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17227] devguide: buggy heading numbers
Carol Willing added the comment: Correct Python Developer FAQ Section 28 to match the style of Section 27. Section numbers should now flow correctly in Sphinx. A section contents is displayed at the top of the section page for the user's convenience (especially since the FAQ questions have long titles). -- assignee: - willingc nosy: +willingc stage: - patch review Added file: http://bugs.python.org/file39111/iss17227.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17227 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions
New submission from Stefan Behnel: The yield-from implementation calls _PyGen_FetchStopIterationValue() to get the exception value. If the StopIteration exception is not normalised, e.g. because it was set by PyErr_SetObject() in a C extension, then _PyGen_FetchStopIterationValue() will cast to (PyStopIterationObject*) whatever the exception value is and happily interpret an arbitrary memory position as PyObject*. I attached a possible patch for the function. Another place to fix it would be in the yield-from code in ceval.c, but directly genobject.c seems the safer place. -- components: Interpreter Core files: fix_stopiteration_crash.patch keywords: patch messages: 241454 nosy: scoder priority: normal severity: normal status: open title: _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions type: crash versions: Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39108/fix_stopiteration_crash.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23996 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23992] multiprocessing: MapResult shouldn't fail fast upon exception
Davin Potts added the comment: This is a nice example demonstrating what I agree is a problem with the current implementation of close. A practical concern with what I believe is being proposed in your trivial fix: if the workers are engaged in very long-running tasks (and perhaps slowly writing their overly large results to the results queue) then we would have to wait for quite a long time for these other workers to reach their natural completion. That said, I believe close should in fact behave just that way and have us subsequently wait for the others to be completed. It is not close's job to attempt to address the general concern I bring up. This change could be felt by people who have written their code to expect the result handler's immediate shutdown if there are no other visible results -- it is difficult to imagine what the impact would be. This is my long-winded way of saying it seems very sensible and welcome to me if you took the time to prepare a patch. -- stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23992 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: HELP! How to return the returned value from a threaded function
On 2015-04-18 18:50, D. Xenakis wrote: This sounds like homework... what have you tried, and what happened? heheh naaah no cheating here. I just provided the example this way to make as clear as possible what I want to do. Return the returned value from a threaded function. apparently this does not work as I hoped: return Thread(target=message_function).start() Have you looked at the docs of the threading module? Lost in there It would be pointless to start a thread to do some work and then wait for it to finish; you might as well do the work yourself! The point of threads is to do work in parallel (actually, that doesn't work that well on CPython because of the GIL) or wait for something that could take a while to respond in the background so that you can continue working on something else in the meantime. The best way of communicating with another thread is via queues: the background thread puts its results into a queue that the main thread can then read. -- https://mail.python.org/mailman/listinfo/python-list
Re: HELP! How to return the returned value from a threaded function
On 04/18/2015 01:07 PM, D. Xenakis wrote: Maybe this is pretty simple but seems I am stuck... def message_function(): return HelloWorld! def thread_maker(): call message_function() using a new thread and return it's HelloWorld! pass Could someone please complete above script so that: thread_maker() == HelloWorld! Please import the library you suggest too. I tried threading but I could not make it work. THX! The first question is why you are even starting extra threads. They are only useful if they do concurrent work. So if you're starting a thread, then not doing anything yourself till the thread terminates, you've gained absolutely nothing. And greatly complicated your code besides. In fact, even if you start multiple threads, and/or continue doing your own work in the main thread, you might not gain anything in CPython, because of the GIL. But if I assume you've justified the use of threads, or your boss/instructor has mandated them, then you still have to decide what the flow of logic is going to mean. If you're going to start a bunch of threads, wait a while, and do something with the return values of some subset of them, then all you need is a way to tell whether those threads have yet posted their results. If there's exactly one result per thread, then all you need is a global structure with room for all the results, and with an initial value that's recognizably different. So fill a list with None elements, and tell each thread what element of the list to update. Then in your main thread, you trust any list element that's no longer equal to None. Alternatively, you might decide your main program will wait till all the threads have terminated. In that case, instead of checking for None, simply do a join on all the threads before using the results. But many real threaded programs use much more complex interactions, and they reuse threads rather than expecting them to terminate as soon as one result is available. So there might not be a single result per thread, and things get much more complex. This is where you would normally start studying queues. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
[issue23999] Undefined behavior in dtoa.c (rshift 32 of 32bit data type)
New submission from Christian Heimes: Coverity has found undefined behavior in dtoa.c:d2b(). lo0bits() can return 32 which z = 32, where z is an uint32. I've talked to doku at PyCon. He suggested to update dtoa.c to a more recent version. Our copy is based on a version from 2001. There are more modern versions available, e.g. https://searchcode.com/codesearch/view/52748288/ from 2006. CID 1202735 (#1 of 1): Bad bit shift operation (BAD_SHIFT) large_shift: In expression z = k, right shifting by more than 31 bits has undefined behavior. The shift amount, k, is 32. -- messages: 241464 nosy: christian.heimes, doko, eric.smith, mark.dickinson, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Undefined behavior in dtoa.c (rshift 32 of 32bit data type) type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23999 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23979] Multiprocessing Pool.map pickles arguments passed to workers
Davin Potts added the comment: Though it's been discussed elsewhere, issue17560 is a good one where the matter of really big objects are being communicated between processes via multiprocessing. In it, Richard shares some detail about the implementation in multiprocessing, its constraints and motivation. That discussion also highlights that the pickler has been made pluggable in multiprocessing since Python 3.3. That is, if you wish, you can use something other than Python's pickle to serialize objects and, in the extreme, potentially communicate them in a completely new way (perhaps even via out-of-band communication, though that was not the intention and would be arguably extreme). I do not think Python's pickle is necessarily what we should expect multiprocessing to use to help communicate objects between processes. Just because pickle is Python's serialization strategy does not also mean it must necessarily also be used in such communications. Thankfully, we have the convenience of using something other than pickle (or newer versions of pickle, since there have been versioned updates to pickle's format over time with some promising improvements). @Luis: To your specific question about the need for Queue, the benefits of a consistent behavior and methodology whether forking/spawning on one OS with its caveats versus another are just that: simplicity. The pluggable nature of the pickler opens up the opportunity for folks (perhaps such as yourself) to construct and plug-in optimized solutions for scenarios or edge cases of particular interest. The fact that we all start with a consistent behavior across platforms and process creation strategies is very appealing from a reduced complexity point of view. -- nosy: +davin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23979 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23995] msvcrt could not be imported
Steve Dower added the comment: You're right, we should be able to remove the ifdef for these (or hide them behind MS_WINDOWS if necessary). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: HELP! How to return the returned value from a threaded function
D. Xenakis gouzouna...@hotmail.com writes: Have you looked at the docs of the threading module? Lost in there You should probably read a book about operating systems to get a sense of how the stuff in there works. The software docs assume you're familiar with the basic principles that you would get from a book or from taking a class. -- https://mail.python.org/mailman/listinfo/python-list
Re: Custom format a la datetime
santiago.basu...@gmail.com wrote:
Hello everybody. I'm writing a CLI program to do some search. It's an
internal tool. I'd like to provide the option to my user to format the
results as he/she'd like. Something similar to strftime on the datetime
module.
Example:
from datetime import datetime
d = datetime.utcnow()
d.strftime(%Y-%m-%d) # '2015-04-18'
d.strftime(%y-%m-%d) # '15-04-18'
d.strftime(Today it's the %dth day in the %mth month of %Y) # 'Today
it's the 18th day in the 04th month of 2015' # Don't pay attention to
ordinals, just simple example.
Now, an example of with my application. Suppose my app search cars:
python search_cars.py -F Brand %B, model %m, year %Y # Brand Ford,
model Focus, year 1996
python search_cars.py -F %B - %m (%y) # Ford - Focus (96)
I'd provide my user with a table like:
%B = Brand
%m = Model
%Y = Year format
%y = Year format YY
%s = Seller name
... etc...
Thanks a lot for your help!
Make a dict to map the format to a function that extracts the value you are
interested in from a record you found with your search. Then replace the
format in the template with the value returned from that function.
import re
record = dict(brand=Ford, model=Focus, year=1996)
format = {B: lambda r: r[brand],
... m: lambda r: r[model],
... Y: lambda r: str(r[year]),
... y: lambda r: {:02}.format(r[year] % 100),
... }
template = Brand %B, model %m, year %Y
re.compile(%(.)).sub(lambda m: format[m.group(1)](record), template)
'Brand Ford, model Focus, year 1996'
template = %B - %m (%y)
re.compile(%(.)).sub(lambda m: format[m.group(1)](record), template)
'Ford - Focus (96)'
To allow literal % signs add
format = {
...
%: lambda r: %
}
to the lookup dict.
For alternative approaches have a look at string.Template, str.format() etc.
--
https://mail.python.org/mailman/listinfo/python-list
[issue23993] Use surrogateescape error handler by default in open() if the LC_CTYPE locale is C at startup
STINNER Victor added the comment: if you are using the C locale you or the OS are broken anyway, so we'll just pass the bytes through Exactly. Even if you use Unicode, the Python 3 str type, you store text as raw bytes (in a custom format, as surrogate characters). I'm not entirely convinced this won't cause issues, but I suppose it might not cause any more issues that having things break due to the C locale does. The most obvious issue is the come back of mojibake. Since you manipulate raw bytes, it's easy to concatenate two bytes strings encoded to two different encodings. https://unicodebook.readthedocs.org/definitions.html#mojibake The problem is that the question is not how bad it is use to manipulate text as bytes. The problem is that a working application written for Python 2 starts to randomly fail (on non-ASCII characters) on Python 3 when the LC_CTYPE locale is the POSIX locale (C). The first question is: should I keep Python 2 or write my application in a language which doesn't force me to understand Unicode? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23993 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16930] mention limitations and/or alternatives to hg graft
Changes by Carol Willing willi...@willingconsulting.com: -- assignee: - willingc nosy: +willingc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16930 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16931] mention work-around to create diffs in default/non-git mode
Changes by Carol Willing willi...@willingconsulting.com: -- assignee: - willingc nosy: +willingc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16931 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Importing/migrating Mailman mbox files into Google Groups?
On 18Apr2015 07:50, Skip Montanaro skip.montan...@gmail.com wrote: On Fri, Apr 17, 2015 at 7:33 PM, Cameron Simpson c...@zip.com.au wrote: However, before you get very excited see if people can get messages back out of the archive. A major annoyance for me with GGroups versus mailman is that if I join a group I cannot download the historical archive. (This is a standard step for me when I join a mailing list. I hear mailman 3 might be tossing this facility; I am unimpressed.) I'll clarify briefly. The archives are from a now-defunct mailing list which accumulated about 190k posts during its nearly ten-year life. The only interface to the archives is a rather feeble search interface. There is no way to just read through the archives in chronological fashion. I know Google Groups isn't very popular here, but trust me, it would provide a much better interface to these archives than the current search interface. I will obviously verify that the messages can be read through GG before dumping all of them into this archive. I think I understood that there was an existing archive. My caveat was more something to consider before choosing GGroups (too late, and in any case hardly a deal breaker, especially since Google finally cleaned up a lot of their HTML/text rendering issues). Maybe I could suggest, in addition to uploading the archive as raw messages for GGroups to present, uploading the archive as a compressed mbox file for members to download if they wish a local archive copy. Cheers, Cameron Simpson c...@zip.com.au Truly, the ultimate demonstration of the computer's utility is that it continues to be indispensable in spite of those who run the things. - Steve Glass, in e-mail -- https://mail.python.org/mailman/listinfo/python-list
[issue15566] tarfile.TarInfo.frombuf documentation is out of date
Martin Panter added the comment: Very simple documentation fix; looks good to me. -- nosy: +vadmium stage: needs patch - commit review versions: +Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15566 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24000] More fixes for the Clinic mapping of converters to format units
New submission from Larry Hastings: I found another bug in the mapping of converters to format units. (s#, z#, and y# all allow zeroes.) I've redone the approach for str_converter in an attempt to make it easier to read. It'd be swell if, after this gets checked in (or rejected), somebody *else* took a pass to see if they could find any bugs. -- assignee: larry files: larry.one.more.clinic.format.unit.map.cleanup.1.txt messages: 241468 nosy: larry, serhiy.storchaka, zach.ware priority: normal severity: normal stage: patch review status: open title: More fixes for the Clinic mapping of converters to format units type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file39113/larry.one.more.clinic.format.unit.map.cleanup.1.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24001] Clinic: use raw types in types= set
New submission from Larry Hastings:
New proposed semantics for the types= parameter to converters: where possible,
pass in actual types. The resulting syntax:
c: int(types={str}) # maps to 'U'
s: str(types={str, robuffer}, length=True, zeroes=True) # maps to 's#'
Since buffer, robuffer, and rwbuffer are fake pseudotypes, I created
empty classes with those names.
Serhiy: with this change in place, the types= parameter uses almost the same
number of characters as it used to when it was a string. (The new syntax
requires commas between elements, so for two or more types it's slightly
longer.) Yet this makes the types= parameter far more accurate in illustrating
what it's supposed to represent.
Does this make you happy? :)
--
assignee: larry
components: Argument Clinic
files: larry.clinic.use.raw.types.1.txt
messages: 241469
nosy: larry, serhiy.storchaka, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Clinic: use raw types in types= set
type: enhancement
Added file: http://bugs.python.org/file39114/larry.clinic.use.raw.types.1.txt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24001
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17227] devguide: buggy heading numbers
Berker Peksag added the comment: Thanks! The patch doesn't address msg182641 and I think this is a Sphinx bug(or perhaps a feature request?). tocdepth should not change the heading numbers. I couldn't find any similar report on the Sphinx issue tracker. So I suggest opening an issue there and closing this one as third party. -- nosy: +berker.peksag ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17227 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15566] tarfile.TarInfo.frombuf documentation is out of date
Roundup Robot added the comment: New changeset d737ab3ea1ae by Berker Peksag in branch '3.4': Issue #15566: Document encoding and errors parameters of TarInfo.frombuf(). https://hg.python.org/cpython/rev/d737ab3ea1ae New changeset 85cba64e24dc by Berker Peksag in branch 'default': Issue #15566: Document encoding and errors parameters of TarInfo.frombuf(). https://hg.python.org/cpython/rev/85cba64e24dc -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15566 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Importing/migrating Mailman mbox files into Google Groups?
On Sat, Apr 18, 2015 at 6:42 PM, Cameron Simpson c...@zip.com.au wrote: I think I understood that there was an existing archive. My caveat was more something to consider before choosing GGroups (too late, and in any case hardly a deal breaker, especially since Google finally cleaned up a lot of their HTML/text rendering issues). One more point. The moderator of this defunct list moved the group from its old place on bikelist.org to Google Groups. It's been there already for several years. I would propose just stuffing the archives into the new group except said moderator made the archives of the new group open only to subscribers. Now that it's been running that way for several years, it's a bit late to open things up. Maybe I could suggest, in addition to uploading the archive as raw messages for GGroups to present, uploading the archive as a compressed mbox file for members to download if they wish a local archive copy. I think the existing archives are in MH format. Shouldn't be too difficult to generate the usual Mailman-style mbox-file-per-month or perhaps one per year. Thx, Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Custom format a la datetime
On Saturday, April 18, 2015 at 5:29:23 PM UTC-3, Peter Otten wrote:
santiago.basu...@gmail.com wrote:
Hello everybody. I'm writing a CLI program to do some search. It's an
internal tool. I'd like to provide the option to my user to format the
results as he/she'd like. Something similar to strftime on the datetime
module.
Example:
from datetime import datetime
d = datetime.utcnow()
d.strftime(%Y-%m-%d) # '2015-04-18'
d.strftime(%y-%m-%d) # '15-04-18'
d.strftime(Today it's the %dth day in the %mth month of %Y) # 'Today
it's the 18th day in the 04th month of 2015' # Don't pay attention to
ordinals, just simple example.
Now, an example of with my application. Suppose my app search cars:
python search_cars.py -F Brand %B, model %m, year %Y # Brand Ford,
model Focus, year 1996
python search_cars.py -F %B - %m (%y) # Ford - Focus (96)
I'd provide my user with a table like:
%B = Brand
%m = Model
%Y = Year format
%y = Year format YY
%s = Seller name
... etc...
Thanks a lot for your help!
Make a dict to map the format to a function that extracts the value you are
interested in from a record you found with your search. Then replace the
format in the template with the value returned from that function.
import re
record = dict(brand=Ford, model=Focus, year=1996)
format = {B: lambda r: r[brand],
... m: lambda r: r[model],
... Y: lambda r: str(r[year]),
... y: lambda r: {:02}.format(r[year] % 100),
... }
template = Brand %B, model %m, year %Y
re.compile(%(.)).sub(lambda m: format[m.group(1)](record), template)
'Brand Ford, model Focus, year 1996'
template = %B - %m (%y)
re.compile(%(.)).sub(lambda m: format[m.group(1)](record), template)
'Ford - Focus (96)'
To allow literal % signs add
format = {
...
%: lambda r: %
}
to the lookup dict.
For alternative approaches have a look at string.Template, str.format() etc.
Amazing! Thank you very much Peter!
--
https://mail.python.org/mailman/listinfo/python-list
[issue23275] Can assign [] = (), but not () = []
Nick Coghlan added the comment: As Raymond notes, this is a fairly harmless quirk - it changes a SyntaxError to an iterable length dependent ValueError: () = [] File stdin, line 1 SyntaxError: can't assign to () [] = () [] = [1] Traceback (most recent call last): File stdin, line 1, in module ValueError: too many values to unpack (expected 0) I only found out about this after being puzzled when a typo in a live demo at PyCon 2015 failed to fail as I expected after seeing the presenter type a [] into the LHS of an assignment instead of the intended _. Removing the data dependence to make the assignment fail immediately (even if never tested against a non-empty iterable) would involve making the handling of List_kind match that of Tuple_kind in the switch statement that eryksun quoted. I don't think it's an urgent fix, but if someone wanted to fix it (including a new test), I think it would be a reasonable contribution to accept. -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23275 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23901] Force console stdout to use UTF8 on Windows
STINNER Victor added the comment: If sys.stdout is modified, it must be carefully tested in various scenario: - Windows console, default config - Windows console, TrueType font - PowerShell = see #21927, it looks like PowerShell has its own set of Unicode issues - Redirect output into a file - etc. Very good articles by Michael S. Kaplan on Windows stdout/console: - Conventional wisdom is retarded, aka What the @#%* is _O_U16TEXT? http://www.siao2.com/2008/03/18/8306597.aspx - Myth busting in the console http://www.siao2.com/2010/10/07/10072032.aspx - Cunningly conquering communicated console caveats. Comprende, mon Capitán? http://www.siao2.com/2010/05/07/10008232.aspx See also fwide() function. Good luck... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23901 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23740] http.client request and send method have some datatype issues
Changes by Akshit Khurana axitkhur...@gmail.com: -- nosy: +axitkhurana ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23740 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23725] update tempfile docs to say that TemporaryFile is secure
Zbyszek Jędrzejewski-Szmek added the comment: v6: - add newline -- Added file: http://bugs.python.org/file39112/tempfile_docs.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15566] tarfile.TarInfo.frombuf documentation is out of date
Berker Peksag added the comment: Thanks! -- nosy: +berker.peksag resolution: - fixed stage: commit review - resolved status: open - closed versions: -Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15566 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23275] Can assign [] = (), but not () = []
Martin Panter added the comment: I would prefer this be fixed in the opposite direction, to allow “unpacking” an empty iterable using round brackets. I have used this syntax on purpose as a concise way to ensure that a generator is exhaused with no more yields: def gen(): ... yield partial computation ... print(computation allowed to complete) ... g = gen() next(g) 'partial computation' [] = g computation allowed to complete -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23275 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: EuroPython 2015: Django Girls Workshop
On Sat, 18 Apr 2015 06:44 am, Larry Martell wrote: On Fri, Apr 17, 2015 at 4:31 PM, Marko Rauhamaa ma...@pacujo.net wrote: beliav...@aol.com: If your target audience is women, I think you should have termed it the Django Womens Workshop rather than the Django Girls Workshop. Referring to adults as children can be seen as condescending. You got it wrong. The name is not offensive. Most adult woman I know take offense at being called a girl. Surely it depends on the context, and also the size of the chip on the person's shoulder. Consider a white male speaking to an adult black American male and referring to him as boy, especially if the white person is younger than the black person. That would be demeaning and offensive due to the history of slavery and apartheid in the US and the continuing status of blacks (especially black males) as second-class citizens in the US. Likewise an Englishman to an adult Indian, although it would probably come across as more laughable than offensive. The British Empire is long gone, and India is an independent nuclear-armed regional power, don't you know? On the other hand, I don't know about where you are, but here in Australia we say I'm going on a night out with the boys, or if we are women, we say a night out with the girls. We might say things like Oh yes, Susan is one of us girls which is quite different from one of us women. (One of us *women* is just a comment on Susan's sex, but *girls* is a comment on her membership of a circle of friends.) Sometimes we say lads and lasses when we want to be less formal than ladies and gentlemen. And of course anyone who has watched Oprah will have heard You go girl! as a positive term of support. It is very common and acceptable to use girls or boys to refer to adults when it is used in an inclusive sense. In other words, when the speaker includes themselves, or at least there is the possibility of being included. I wish I could be one of the boys, but I'm just to shy to join in. In *this specific instance*, all you guys complaining about Django Girls have completely missed the important fact that the name of the group is Django Girls. Django Girls was started by two women, Ola Sitarska and Ola Sendecka, and their Github page says: Django Girls is a programming workshop for women. So it is not a Django workshop for female children. It is not a workshop belonging to girls who happen to use Django. It might not even be a workshop teaching how to use Django! (Although it probably will be.) It is a Django Girls workshop, just like we might say Microsoft technology or Washington politics. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Huh? No way to markup announcements here?
On Sat, 18 Apr 2015 08:24 pm, edream...@gmail.com wrote: Many google groups support markdown or other markup. I see no mention of markup here: https://www.python.org/community/clpya-guidelines.txt/ Is there any way to format announcements? If so, how. If not, why not? If your announcement is so boring that you think you have to Jazz It Up with animated gifs, multiple typefaces and so forth, perhaps you should rethink whether or not you should bother announcing it. Of course you can use *ReST* or *Markdown* here. It's just plain text. Clients which support it will render the text appropriately, and clients which don't will display it as plain text. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: EuroPython 2015: Django Girls Workshop
On Sunday, April 19, 2015 at 9:05:54 AM UTC+5:30, Steven D'Aprano wrote: On Sat, 18 Apr 2015 06:44 am, Larry Martell wrote: On Fri, Apr 17, 2015 at 4:31 PM, Marko Rauhamaa wrote: beliavsky: If your target audience is women, I think you should have termed it the Django Womens Workshop rather than the Django Girls Workshop. Referring to adults as children can be seen as condescending. You got it wrong. The name is not offensive. Most adult woman I know take offense at being called a girl. Surely it depends on the context, and also the size of the chip on the person's shoulder. Consider a white male speaking to an adult black American male and referring to him as boy, especially if the white person is younger than the black person. That would be demeaning and offensive due to the history of slavery and apartheid in the US and the continuing status of blacks (especially black males) as second-class citizens in the US. Likewise an Englishman to an adult Indian, although it would probably come across as more laughable than offensive. The British Empire is long gone, and India is an independent nuclear-armed regional power, don't you know? On the other hand, I don't know about where you are, but here in Australia we say I'm going on a night out with the boys, or if we are women, we say a night out with the girls. We might say things like Oh yes, Susan is one of us girls which is quite different from one of us women. (One of us *women* is just a comment on Susan's sex, but *girls* is a comment on her membership of a circle of friends.) Sometimes we say lads and lasses when we want to be less formal than ladies and gentlemen. And of course anyone who has watched Oprah will have heard You go girl! as a positive term of support. It is very common and acceptable to use girls or boys to refer to adults when it is used in an inclusive sense. In other words, when the speaker includes themselves, or at least there is the possibility of being included. I wish I could be one of the boys, but I'm just to shy to join in. In *this specific instance*, all you guys complaining about Django Girls have completely missed the important fact that the name of the group is Django Girls. Django Girls was started by two women, Ola Sitarska and Ola Sendecka, and their Github page says: Django Girls is a programming workshop for women. So it is not a Django workshop for female children. It is not a workshop belonging to girls who happen to use Django. It might not even be a workshop teaching how to use Django! (Although it probably will be.) It is a Django Girls workshop, just like we might say Microsoft technology or Washington politics. I remember being taught in school: lady is respectful woman is disrespectful When I was recently in Canada I learnt its exactly the other way round there -- [And probably more so in US where the chips on shoulder are heftier] I was told by a lady -- uh... woman -- not to say 'ladies' but 'women' -- https://mail.python.org/mailman/listinfo/python-list
[issue24001] Clinic: use raw types in types= set
Larry Hastings added the comment: Should types= be renamed accept= ? It's a set of the types of the Python objects that this parameter should accept. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24001 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
