[issue5818] Fix five small bugs in the bininstall and altbininstall pseudotargets
New submission from Larry Hastings la...@hastings.org: Makefile.pre.in as checked in has several small bugs: First, the altbininstall target runs ln -s without first ensuring the destination doesn't exist. If you run make install twice, without manually deleting $prefix/bin/python3 between the runs, the ln fails and make aborts. This happens pretty early in the install process, so for example this means you can't edit a module in Lib and re-install it. Second, the bininstall target no longer installs a python executable. It should hard-link python to python3.1--as indeed is the entire point of having the bininstall target--but it doesn't. (I was quite surprised by this. I would have asked the person who removed it--but svn blame doesn't show you who *removed* a line, and I didn't have the inclination to go bisecting to sleuth it out on my own.) Third, when altbininstall and bininstall write the python3.1 and python executables in the prefix directory, they also create corresponding python3.1-config and python-config configuration reporting scripts. But altbininstall doesn't create a python3-config to go with python3. Fourth, maninstall is only run as part of bininstall, not altbininstall. This means that you only got the python3.1 man page if you ran bininstall, and we all know running bininstall is not recommended. Fifth, bininstall and altbininstall don't properly honor $EXE; sometimes they specify it and sometimes they don't. To be honest I'm not sure this matters in the slightest. $EXE is only non-empty for Windows builds, and Windows has a completely separate build process. And even if you used the Makefile to build, I cannot imagine you using it to install. Still, a foolish consistency is the hobgoblin of my little mind. My patch fixes all of the above. While I was staring at it, I also touched up some comments. One final question: why do we use soft-links to python3.1-config but hard links to python3.1? -- components: Build files: lch.makefile.r71812.diff keywords: patch messages: 86350 nosy: lhastings severity: normal status: open title: Fix five small bugs in the bininstall and altbininstall pseudotargets versions: Python 3.1 Added file: http://bugs.python.org/file13744/lch.makefile.r71812.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5818 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5818] Fix five small bugs in the bininstall and altbininstall pseudotargets
Larry Hastings la...@hastings.org added the comment: Minor correction for the First bug mentioned: altbininstall is running ln, not ln -s. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5818 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5819] Add PYTHONPREFIXES environment variable
New submission from Larry Hastings la...@hastings.org:
The attached patch adds support for a new environment variable,
PYTHONPREFIXES. PYTHONPREFIXES is similar to PYTHONUSERBASE: it lets
you add prefix directories to be culled for site packages. It differs
from PYTHONUSERBASE in three ways:
* PYTHONPREFIXES has an empty default value. PYTHONUSERBASE has a
default, e.g. ~/.local on UNIX-like systems.
* PYTHONPREFIXES supports multiple directories, separated by the
site-specific directory separator character (os.pathsep). Earlier
directories take precedence. PYTHONUSERBASE supports specifying
at most one directory.
* PYTHONPREFIXES adds its directories to site.PREFIXES, so it reuses
the existing mechanisms for site package directories, exactly
simulating a real prefix directory. PYTHONUSERBASE only adds a
single directory, using its own custom code path.
This last point bears further discussion. PYTHONUSERBASE's custom code
to inspect only a single directory has resulted in at least one bug, if
not more, as follows:
* The bona-fide known bug: the Debian package mantainer for Python
decided to change site-packages to dist-packages in 2.6,
for reasons I still don't quite understand. He made this change in
site.addsitepackages and distutils.sysconfig.get_python_lib, and
similarly in setuptools, but he missed changing it in
site.addusersitepackages. This meant that if you used setup.py to
install a package to a private prefix directory, PYTHONUSERBASE had
no hope of ever finding the package. (Happily this bug is fixed.)
* I suspect there's a similar bug with PYTHONUSERBASE on the os2emx
and riscos platforms. site.addsitepackages on those platforms
looks in {prefix}/Lib/site-packages, but
site.addusersitepackages looks in
{prefix}/lib/python{version}/site-packages as it does
on any non-Windows platform. Presumably setup.py on those two
platforms installs site packages to the directory site.addsitepackages
inspects, which means that PYTHONUSERBASE doesn't work on those
two platforms.
PYTHONUSERBASE's custom code path to add site package directories is a
source of unnecessary complexity and bugs. I cannot fathom why its
implementors chose this approach; in any case I think reusing
site.addsitepackages is a clear win. I suspect it's too late to change
the semantics of PYTHONUSERBASE to simply call site.addsitepackages,
though if that idea found support I'd be happy to contribute a patch.
A few more notes on PYTHONPREFIXES:
* PYTHONPREFIXES is gated by the exact same mechanisms that shut off
PYTHONUSERBASE.
* Specifying -s on the Python command line shuts it off.
* Setting the environment variable PYTHONNOUSERSITE to a non-empty
string shuts it off.
* If the effective uid / gid doesn't match the actual uid / gid it
automatically shuts off.
* I'm not enormously happy with the name. Until about an hour or two
ago I was calling it PYTHONUSERBASES. I'm open to other
suggestions.
* I'm not sure that PYTHONPREFIX should literally modify site.PREFIXES.
If that's a bad idea I'd be happy to amend the patch so it didn't
touch site.PREFIXES.
* Reaction in python-ideas has been reasonably positive, though I gather
Nick Coughlan and Scott David Daniels think it's unnecessary. (To
read the discussion, search for the old name: PYTHONUSERBASES.)
* Ben Finney prefers a counter-proposal he made in the python-ideas
discussion: change the existing PYTHONUSERBASE to support multiple
directories. I don't like this approach, because:
a) it means you have to explicitly add the local default if you
want to use it, and
b) PYTHONUSERBASE only inspects one directory, whereas PYTHONPREFIX
inspects all the directories Python might use for site packages.
I do admit this approach would be preferable to no change at all.
The attached patch is thrillingly simple and works fine. However it's
not ready to be merged because I haven't touched the documentation. I
figured I'd hold off until I see which way the wind blows.
I'd also be happy to whip out a PEP if that's what is called for.
--
files: lch.pythonprefixes.r71812.diff
keywords: patch
messages: 86352
nosy: lhastings
severity: normal
status: open
title: Add PYTHONPREFIXES environment variable
Added file: http://bugs.python.org/file13745/lch.pythonprefixes.r71812.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5819
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5819] Add PYTHONPREFIXES environment variable
Larry Hastings la...@hastings.org added the comment: Whoops, didn't classify the patch before submission. -- components: +Library (Lib) type: - feature request versions: +Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5816] Simplify parsing of complex numbers and make complex('inf') valid.
Mark Dickinson dicki...@gmail.com added the comment:
Updated patch:
4. also simplify complex printing: no special handling for nans or
infinities. This means that e.g. complex(1, inf) prints as
1 + infj instead of 1+inf*j.
This might look ugly, but I think it's better than what was there
before. Complex reprs are now more uniform and easier to parse
by external code. And the expression 1 + inf*j doesn't give
the right thing anyway, even if you replace j by 1j and inf by
float(inf):
inf = float('inf')
1 + inf*j
Traceback (most recent call last):
File stdin, line 1, in module
NameError: name 'j' is not defined
1 + inf*1j # expect (1+infj), but get nan in real part:
(nan+infj)
Furthermore, with these simplifications to printing and
parsing, roundtripping now works: the output of repr(z)
is valid input to
5. Print real part if it's negative zero: z =complex(-0.0, 0.0)
now prints as -0 + 0j instead of just 0j, so again roundtripping
works: complex(repr(z)) recovers z exactly.
6. Change PyOS_ascii_strtod to always output a sign when requested,
even for nans. As far as I can tell, the complex formatting is
the only place that's affected by this. Eric?
--
nosy: +eric.smith
Added file: http://bugs.python.org/file13746/simplify_complex_parsing_v2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5816
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5820] Very small bug in documentation of json.load()
New submission from P.C. Shyamshankar syk...@lucentbeing.com: The suggestion that non-ASCII based encodings should be wrapped in a codecs.getreader instance has a small bug, ie instead of codecs.getreader(fp)(encoding), it should be the other way around, codecs.getreader(encoding)(fp). It's a very small bug, and I've got a very small patch for it. It's my first bug report/patch, so please tell me if I've done something stupid :) -- assignee: georg.brandl components: Documentation files: json_patch.diff keywords: patch messages: 86355 nosy: georg.brandl, sykora severity: normal status: open title: Very small bug in documentation of json.load() versions: Python 3.1 Added file: http://bugs.python.org/file13747/json_patch.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5820 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5820] Very small bug in documentation of json.load()
Georg Brandl ge...@python.org added the comment: It's all right! Thanks for the patch, committed in r71814. -- resolution: - accepted status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5820 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5813] Pointer into language reference from __future__ module documentation
Georg Brandl ge...@python.org added the comment: I added a seealso in r71816. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5813 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5816] Simplify parsing of complex numbers and make complex('inf') valid.
Eric Smith e...@trueblade.com added the comment:
Wow, that does greatly simplify printing. One nit: the variable named
'im' isn't needed any more, you could just use 'pim'. Not sure if the
asymmetry with 're' and 'pre' is worthwhile, though.
Mark Dickinson wrote:
6. Change PyOS_ascii_strtod to always output a sign when requested,
even for nans. As far as I can tell, the complex formatting is
the only place that's affected by this. Eric?
That's correct. It might make a difference when fixing issue 4482,
though, at least for the %-formatting case. So if you're going to check
this in, sooner is better than later for me.
Also, could this be backported to 2.7, so that 4482 can be fixed the
same way in both versions?
--
title: Simplify parsing of complex numbers and make complex('inf') valid. -
Simplify parsing of complex numbers and make complex('inf') valid.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5816
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5816] Simplify parsing of complex numbers and make complex('inf') valid.
Eric Smith e...@trueblade.com added the comment: The fallback code, around line 633 in the patched version of pystrtod.c, probably also needs to be modified. It's this code that would need backporting to 2.7. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5816 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1540386] SocketServer.ForkingMixIn.collect_children() waits on pid 0
Stefan Ring stefan...@gmail.com added the comment: Jeffrey, this very commit broke it. See also issue 5814. The same happened for me last week. What makes it especially bad is that even once enough children terminate, the SocketServer won't be able to handle any more connections; it just throws this Exception again and again and closes new connections immediately. -- nosy: +Ringding ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1540386 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1109963] bdist_wininst ignores build_lib from build command
Andrew I MacIntyre aimacint...@users.sourceforge.net added the comment: The offending code appears to have been introduced in r33090 and tweaked in r37025, which both originated from Mark Hammond. From the comments, there seems to be no reason why the build_lib override should apply when the target version is specifically different from the version being used to build the extension, hence I've attached a patch which applies the override only when the versions are different (for both bdist_wininst and bdist_msi). This doesn't solve the problem that exists when the target and build versions are different and build_lib has been overridden in setup.py (as I understand is the case with cx_Oracle). I've added Mark to the nosy list in the hope he might, as originator of the problematic changes, be able to provide some insight. -- keywords: +patch nosy: +aimacintyre, mhammond Added file: http://bugs.python.org/file13748/python_issue_1109963.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1109963 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1533520] Allow thread(ing) tests to pass without setting stack size
Andrew I MacIntyre aimacint...@users.sourceforge.net added the comment: Pretty much all the test structure in the patch has made it through the re-write to unittest, so closed as out of date. -- resolution: - out of date status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1533520 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3868] patch for review: OS/2 EMX port fixes for 2.6
Changes by Andrew I MacIntyre aimacint...@users.sourceforge.net: -- status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3868 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1074333] input from numeric pad always dropped when numlock off
Guilherme Polo ggp...@gmail.com added the comment: Unfortunately this is not that easy for us, while we could add some code like this: import Tkinter text = Tkinter.Text() text.event_add(Up, Key-Up) text.event_add(Up, Key-KP_Up) text.bind_class(Text, Up, text.bind_class(Text, Key-Up)) text.pack() text.mainloop() it won't work as most would expect. When numlock is on, it would still move one line up. We could change it to fix this problem, but then we would be using tk::TextUpDownLine which is marked as unsupported (basically everything that could help us in such situations is marked as unsupported). I will be asking someone about all these unsupported commands. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1074333 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1074333] input from numeric pad always dropped when numlock off
Guilherme Polo ggp...@gmail.com added the comment:
When numlock is on, it would still
move one line up. We could change it to fix this problem, but then we
would be using tk::TextUpDownLine which is marked as unsupported
(basically everything that could help us in such situations is marked as
unsupported).
Ah yes, here is something that would do what we wanted (for up only):
import Tkinter
def my_up(event):
widget = event.widget
if event.keysym == 'KP_Up' and event.state 16:
widget.tk.call('tk::TextInsert', widget, event.char)
return break
pos = widget.tk.call('tk::TextUpDownLine', widget, -1)
widget.tk.call('tk::TextSetCursor', widget, pos)
text = Tkinter.Text()
text.event_add(Up, Key-Up)
text.event_add(Up, Key-KP_Up)
text.bind_class(Text, Up, my_up)
text.pack()
text.mainloop()
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1074333
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4608] urllib.request.urlopen does not return an iterable object
Senthil orsent...@gmail.com added the comment: This issue is already fixed by jeremy at Revision 70815, wherein The response from an HTTP request is now an HTTPResponse instance instead of an addinfourl() wrapper instance. So the issue won't be present in the py3k code ( confirmed). However, the test added by Daniel,which tests for urlopen() for a request which is bverylong * 8192 still fails. It is not just with iteration; but test_200 will fail too if the request is a large chunk. This is only in py3k branch, test will pass in the trunk code. I am investigating further. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4608 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5821] Documentation: mention 'close' and iteration for tarfile.TarFile.extractfile()
New submission from Ben North benno...@users.sourceforge.net: The current documentation for tarfile.TarFile.extractfile() does not mention that the returned 'file-like object' supports close() and also iteration. The attached patch (against svn trunk) fixes this. (Background: I was wondering whether I could write def process_and_close_file(f_in): with closing(f_in) as f: # Do stuff with f. and have it work whether f_in was a true file or the return value of extractfile(), and thought from the documentation that I couldn't. Of course, I could have just tried it, but I think fixing the documentation wouldn't hurt.) -- assignee: georg.brandl components: Documentation files: tarfile.rst.patch keywords: patch messages: 86366 nosy: bennorth, georg.brandl severity: normal status: open title: Documentation: mention 'close' and iteration for tarfile.TarFile.extractfile() type: feature request Added file: http://bugs.python.org/file13749/tarfile.rst.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5821 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3493] No Backslash (\) in IDLE 1.2.2
Guilherme Polo ggp...@gmail.com added the comment: Can you verify if it is possible to type '\' in a standard Tkinter.Text ? -- nosy: +gpolo type: feature request - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3493 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1540386] SocketServer.ForkingMixIn.collect_children() waits on pid 0
Jeffrey Yasskin jyass...@gmail.com added the comment: Yes, sorry. That was fixed in r69927. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1540386 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1525806] Tkdnd mouse cursor handling patch
klappnase klappn...@users.sourceforge.net added the comment: Maybe this depends on whether the dragged item is clickable like listbox items and buttons or not , like the Labels in the Tkdnd demo. Ok, I wrote a second patch that solves this by adding another option to dnd_start(); if this option is set to True (the default) the user gets the classic behavior, if set to False the cursor changes when the motion starts, as in the initial patch. I couldn't figure out a good name for this option, so I called it swapcursoronclick, at least the name says what it is for ^_^ -- Added file: http://bugs.python.org/file13750/Tkdnd.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1525806 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5819] Add PYTHONPREFIXES environment variable
Ian Bicking i...@colorstudy.com added the comment: This has a similar purpose to virtualenv, but using an environmental variable. An earlier package, workingenv, also used an environmental variable, and this led to a set of problems. The biggest problem is that the environmental variable is inherited by subprocesses. This means if you install hg globally, then do subprocess.call(['hg', ...]), then hg will have picked up your local environment. Sometimes this is what you want (e.g., when using ipython) and sometimes not (probably not when using hg). Another problem is that scripts aren't really sticky with respect to the environment. When you install a script using this, it may only work when that same environmental variable is set. But the script remains present and callable regardless. Also, it's hard to mix and match environments in this system. These are real-world problems I encountered with workingenv, and virtualenv has resolved them very reliably by instead using sys.executable to select the environment. This requires some infrastructure in each environment which is unfortunate, but the result is more consistent behavior. -- nosy: +ianb ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5819] Add PYTHONPREFIXES environment variable
Ian Bicking i...@colorstudy.com added the comment: Also with respect to the patch, for consistency there needs to be changes to distutils to make use of this variable. PYTHONUSERBASE included changes so that you can install based on that variable. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3493] No Backslash (\) in IDLE 1.2.2
Changes by Terry J. Reedy tjre...@udel.edu: -- nosy: -tjreedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3493 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5822] inconsistent behavior of range when used in combination with remove
New submission from Michael Gilbert michael.s.gilb...@gmail.com: using range in combination with remove is inconsistent. for example in python 2.x: x = range(0,3) x.remove(1) x [0, 2] x = range(0,3).remove(1) x and in python 3.x: x = list(range(0,3)) x.remove(1) x [0, 2] x = list(range(0,3)).remove(1) x why does the second approach remove all items from the list? -- components: Interpreter Core messages: 86372 nosy: zero79 severity: normal status: open title: inconsistent behavior of range when used in combination with remove type: behavior versions: Python 2.5, Python 2.6, Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5822 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5816] Simplify parsing of complex numbers and make complex('inf') valid.
Mark Dickinson dicki...@gmail.com added the comment: Committed to py3k, r71818, with the changes Eric suggested. I ran build and tests both with and without the -DPY_NO_SHORT_FLOAT_REPR compiler option. Will backport. -- versions: +Python 2.7 -Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5816 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5822] inconsistent behavior of range when used in combination with remove
R. David Murray rdmur...@bitdance.com added the comment: [1,2,3].remove(1) repr([1,2,3].remove(1)) 'None' The remove method mutates the list, and therefore like all such mutating methods, it returns None. -- nosy: +r.david.murray resolution: - invalid stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5822 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5822] inconsistent behavior of range when used in combination with remove
Michael Gilbert michael.s.gilb...@gmail.com added the comment: ok, i see now. the list itself is changed in place, and the return value of the remove() method is always None. since i din't assign the list to a variable in the first place, there is hence no way now to access that modified list. thanks for your help. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5822 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5823] feature request: a conditional for statement
New submission from Michael Gilbert michael.s.gilb...@gmail.com: hello, i've recently been working on some code where i am processing a list, but excluding certain items. the solution is to use a list comprehension in the for statement, which for example looks like: for m in [n for n in range( 0 , 5 ) if n != 2] determining what's going on here isn't immediately obvious (i.e. what's this new variable n doing?). it would be nice to have a more streamlined syntax such as: for m in range( 0 , 5 ) with m != 2 which is much cleaner and obvious. the statements following with could be any conditional expression. this is just a wishlist item, and i understand that it wouldn't have much priority in the grand scheme of things. thank you for your consideration. -- components: Interpreter Core messages: 86377 nosy: zero79 severity: normal status: open title: feature request: a conditional for statement type: feature request versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5823 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5823] feature request: a conditional for statement
Benjamin Peterson benja...@python.org added the comment: You should bring this up on the python-ideas mailing list. I'm closing this unless it gets support on that list or python-dev. -- nosy: +benjamin.peterson resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5823 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5823] feature request: a conditional for statement
Michael Gilbert michael.s.gilb...@gmail.com added the comment: hello, i've recently been working on some code where i am processing a list, but excluding certain items. the solution is to use a list comprehension in the for statement, which for example looks like: for m in [n for n in range( 0 , 5 ) if n != 2] determining what's going on here isn't immediately obvious (i.e. what's this new variable n doing?). it would be nice to have a more streamlined syntax such as: for m in range( 0 , 5 ) with m != 2 which is much cleaner and obvious. the statements following with could be any conditional expression. this is just a wishlist item, and i understand that it wouldn't have much priority in the grand scheme of things. thank you for your consideration. -- nosy: -benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5823 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5824] SocketServer.DatagramRequestHandler Broken under Linux
New submission from Jim Dennis answr...@gmail.com: .../lib/python2.*/SocketServer.py in class DatagramRequestHandler contains the following comment: # XXX Regrettably, I cannot get this working on Linux; # s.recvfrom() doesn't return a meaningful client address. This is a poor way to document the limitation. Someone writing code and carefully adhering to the documentation will be presented with an exception that stems from this and forced to read source code for the standard libraries to understand why it's not behaving as documented. In Issue1767511 it was recommended that the finish() method only call sendto() if wfile.getvalue() returns a meaningful value. (The bug here is that this returns None under Linux and the default handler calls sendto on it anyway). Perhaps it would be better to raise an exception with a clear error message (Not supported on this platform) and to update the standard documentation to clarify the need to over-ride the .finish() method if one does NOT want a response automatically sent back. (The fact that finish() does a sendto() seems like a poor default for a UNIX domain socket --- for use with the UnixDatagramServer class --- in any event. That leads to a loop in .server_forever() where the instance is reading its own response). In fact the whole question of whether the DatagramRequestHandler should be used with a UnixDatagramServer is reasonable. If it's a nonsensical combination then perhaps some sort of check could be implemented to raise an exception ... or at least a sensible alternative should be added to the standard documentation. Example: #!/usr/bin/env python import SocketServer usock = '/var/tmp/pong' class PongHandler(SocketServer.DatagramRequestHandler): '''Play ping pong over datagram sockets ''' def handle(self): '''Respond to any request with Pong ''' pass def finish(self): '''Necessary under Linux to prevent: Exception: File /usr/lib/python2.5/SocketServer.py, line 588, in finish self.socket.sendto(self.wfile.getvalue(), self.client_address) TypeError: argument must be string or read-only character buffer, not ''' if self.wfile.getvalue(): SocketServer.DatagramRequestHandler.finish(self) if __name__ == '__main__': SocketServer.UnixDatagramServer(usock, PongHandler).serve_forever() ... and testing this with: #!/usr/bin/env python import socket USOCK = /var/tmp/pong if __name__ == '__main__': sock = socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM) sock.sendto(Ping, USOCK) -- components: Library (Lib) messages: 86380 nosy: jimd severity: normal status: open title: SocketServer.DatagramRequestHandler Broken under Linux type: behavior versions: Python 2.4, Python 2.5, Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5824 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5824] SocketServer.DatagramRequestHandler Broken under Linux
Jim Dennis answr...@gmail.com added the comment: Addendum: What I said about the default sendto() in finish() causing a loop in server_forever() was wrong. I'd seen that behavior in an experimental variation of the code. The exceptions raised (and deficiencies in documentation) are the issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5824 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1109963] bdist_wininst ignores build_lib from build command
Mark Hammond mhamm...@users.sourceforge.net added the comment: So it looks like I broke the ability to override --build-lib :( Without testing, I think you might also need to handle the cross-compile case - the version may be the same, but the platform different. I know distutils is a PITA so might make this difficult, but it might be better that we only set build_lib if the user didn't - ie, trust the user knows what they are doing if they specify that option, even in these 'mismatched version/platform' cases. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1109963 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5819] Add PYTHONPREFIXES environment variable
Larry Hastings la...@hastings.org added the comment: Thanks for your battle-tested feedback, Mr. Bicking! I reply inline. The biggest problem is that the environmental variable is inherited by subprocesses. [...] Another problem is that scripts aren't really sticky with respect to the environment. [...] These are real-world problems I encountered with workingenv, and virtualenv has resolved them very reliably by instead using sys.executable to select the environment. Excellent points. PYTHONPREFIXES is not a virtualization cure-all; for a complete solution you clearly need an executable file for folks to hang their hat on. However: wouldn't PYTHONPREFIXES greatly simplify virtualenv? All you should need is an executable and a sitecustomize module. Your executable would set PYTHONPREFIXES as makes sense and run Python. Your usercustomize would: * set sys.executable, * set sys.prefix (and maybe sys.exec_prefix), * *unset* PYTHONPREFIXES, and * run the user's real sitecustomize if present. If this works reliably it would obviate most of the work virtualenv currently has to do. In fact I just tried this. A two-line shell script for python3, a twenty-line sitecustomize.py, installed lib/python3.1/config/Makefile and include/python3.1 in my virtualized environment, and I was able to install HeapDict for python3 using its setup.py. (PyPI lies, though; HeapDict doesn't work unmodified in python3. It calls callable(). But once I fixed that it ran fine.) So it passes a smoke-test at least. Also, it's hard to mix and match environments in this system. How so? I thought this proposal made it far easier to mix and match environments. PYTHONPREFIXES is a stack; push and pop environments as you like. Also with respect to the patch, for consistency there needs to be changes to distutils to make use of this variable. PYTHONUSERBASE included changes so that you can install based on that variable. Good call. I found it infuriating that setuptools didn't (still doesn't iirc) understand PYTHONUSERBASE, and would complain that the --prefix directory doesn't support .pth files. If this patch goes further I'll fix up distutils. Thanks again for your feedback! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Robert Kern robert.k...@gmail.com added the comment: Is there any interest in my expanding the list of probes? Ruby has quite a few more than function-entry and function-return, to give some examples of what is possible: http://dev.joyent.com/projects/ruby-dtrace/wiki/Ruby+DTrace+probes+and+arguments I think that adding probes that correspond to PyTrace_LINE and PyTrace_EXCEPTION would be straightforward and worthwhile. PyTrace_C_* may also be worthwhile, but you can probably accomplish similar things with the normal pid probes if you know the C function names (although something like printing the name of a raised exception will probably require a dedicated probe). Adding probes to replicate what the LLTRACE configuration option did, but dynamically, might be interesting. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Jesús Cea Avión j...@jcea.es added the comment: Is there any interest in my expanding the list of probes? Definitively!!!. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1794] Hot keys must work in any keyboard layout
Guilherme Polo ggp...@gmail.com added the comment:
That bug report is talking about gtk and modifiers affecting bindings
(in the first comments at least), or maybe it even talks about your
problem but it is so long that I would ask to include the relevant parts
here.
Nevertheless, after reading your comments I came to the conclusion that
doing what you want is very unlikely to happen. To bind something in Tk
you have to a specify a string like Control-x, but to do what you
want, it would have to change to:
import Tkinter
def test(event):
if event.keysym_num == ord('x') and event.state 4:
print Ctrl-x!
root = Tkinter.Tk()
root.bind('KeyPress', test)
root.mainloop()
Maybe you can test this and verify if it works like you wanted. But I
really don't see IDLE changing to work like that.
--
components: +IDLE -Tkinter
nosy: +gpolo
type: - feature request
versions: -Python 2.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1794
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5825] Patch to add remove method to tempfile.NamedTemporaryFile
New submission from Miki Tebeka miki.teb...@gmail.com: Adding remove method to NamedTemporaryFile will reduce the need to import os.unlink when creating a NamedTemporaryFile with delete=False. -- components: Library (Lib) files: tempfile.diff keywords: patch messages: 86387 nosy: tebeka severity: normal status: open title: Patch to add remove method to tempfile.NamedTemporaryFile type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file13752/tempfile.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5825 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5826] new unittest function listed as assertIsNotNot() instead of assertIsNotNone()
New submission from Mike Rooney mroo...@gmail.com: On http://docs.python.org/dev/py3k/whatsnew/3.1.html under unittest changes, you will find the last new function listed is assertIsNotNot() instead of assertIsNotNone() -- assignee: georg.brandl components: Documentation messages: 86388 nosy: georg.brandl, mrooney severity: normal status: open title: new unittest function listed as assertIsNotNot() instead of assertIsNotNone() versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5826 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Skip Montanaro s...@pobox.com added the comment: Robert Is there any interest in my expanding the list of probes? Yes. Jeff Garrett (a guy I work with) added some more DTrace probes to a 2.4 source tree at work. I mentioned them in an earlier message. I'll check with him at work tomorrow and see about making sure they can be released. I think it's important to get Sun and Apple in sync as well. Maybe more important than adding new probes. (Though if the Python community drives the creation of new probes perhaps both will pick them up.) Skip -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3613] base64.encodestring does not actually accept strings
Matt Giuca matt.gi...@gmail.com added the comment: I've attached a patch which renames encodestring to encodebytes (keeping encodestring around as an alias). Updated test and documentation. I also renamed decodestring to decodebytes, because it also refuses to accept a string (only a bytes). I have an alternative suggestion, which I'll post in a separate comment (in a minute). -- Added file: http://bugs.python.org/file13753/encodestring_rename.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3613 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3613] base64.encodestring does not actually accept strings
Matt Giuca matt.gi...@gmail.com added the comment: Now, base64.encodestring and decodestring seem a bit weird because the Base64 encoded string is also required to be a bytes. It seems to me that once something is Base64-encoded, it's considered to be ASCII text, not just some byte string, and therefore it should be a str, not a bytes. (For example, they end with a '\n'. That's something which strings do, not bytes). Hence, base64.encodestring (which should be encodebytes) should take a bytes and return a str. base64.decodestring should take a str (required to be ASCII-only) and return a bytes. I've attached an alternative patch, encodebytes_new_types.patch (which, unlike my other patch, doesn't rename decodestring to decodebytes). This patch: - Renames encodestring to encodebytes. - Changes the output of encodebytes to return an ASCII str*, not a bytes. - Changes the input of decodestring to accept an ASCII str, not a bytes. * An ASCII str is a Unicode string with only ASCII characters. This isn't a proper patch (it breaks a lot of other code which I haven't bothered to fix). I'm just submitting it as an idea, in case this is something we want to do. Most likely not, due to the breakage. Also we have the same problem for the non-legacy functions, b64encode and b64decode, etc, so the problem is more widespread than just these two functions. -- Added file: http://bugs.python.org/file13754/encodebytes_new_types.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3613 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Robert Kern robert.k...@gmail.com added the comment: We could probably merge Apple's and Sun's probes without too much trouble. Apple simply extended function-entry to include the argcount in addition to Sun's (filename, funcname, lineno) arguments. We could use Apple's probe while retaining compatibility with Sun-oriented DTrace scripts already in existence. The two different function-returns are a bit of a problem. I recommend starting with Sun's argument list because there are already a number of quite useful scripts that use it in the DTraceToolkit. We could extend Sun's argument list to add the *object pointer, but I don't actually know of a use case. I haven't seen a script in the wild that uses it. It seems like it would be tricky to write something in a DTrace script that could make much use of it besides printing out the address. Maybe you could navigate your way down to the type name, but that might be unreliable. I suggest adding the *object pointer argument only if we can devise a use case or if one of the Apple folks pop up with one. I don't feel too bad making Apple devs modify a single character from their internal scripts if they don't make them public. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3565] array documentation, method names not 3.0 compliant
Matt Giuca matt.gi...@gmail.com added the comment: OK since the patches I submitted are now eight months old, I just did an update and re-applied them. I am submitting new patch files which don't change anything, but are patches against revision 71822 (should be much easier to apply). I'd still like to see doc+bytesmethods.patch applied (since it fixes method names which make no sense at all in Python 3.0 context), but since it's getting a bit late for that, I'll be happy for the doc-only patch to be accepted (which merely corrects the documentation which is still using Python 2.x terminology). -- Added file: http://bugs.python.org/file13755/doc-only.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3565 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3565] array documentation, method names not 3.0 compliant
Matt Giuca matt.gi...@gmail.com added the comment: Full method renaming patch. -- Added file: http://bugs.python.org/file13756/doc+bytesmethods.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3565 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5827] os.path.normpath doesn't preserve unicode
New submission from Matt Giuca matt.gi...@gmail.com: In the Python 2.x branch, os.path.normpath will sometimes return a str even if given a unicode. This is not an issue in the Python 3.0 branch. This happens specifically when it throws away all string data and constructs its own: os.path.normpath(u'') '.' os.path.normpath(u'.') '.' os.path.normpath(u'/') '/' This is a problem if working with code which expects all strings to be unicode strings (sometimes, functions raise exceptions if given a str, when expecting a unicode). I have attached patches (with test cases) for posixpath and ntpath which correctly preserve the unicode-ness of the input string, such that the new behaviour is: os.path.normpath(u'') u'.' os.path.normpath(u'.') u'.' os.path.normpath(u'/') u'/' I tried it on os2emxpath and plat-riscos/riscospath (the other two OS-specific path modules), and it already worked fine for them. Therefore, this patch fixes all necessary OS-specific versions of os.path. -- components: Library (Lib), Unicode files: normpath.patch keywords: patch messages: 86395 nosy: mgiuca severity: normal status: open title: os.path.normpath doesn't preserve unicode versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file13757/normpath.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5827 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5827] os.path.normpath doesn't preserve unicode
Changes by Matt Giuca matt.gi...@gmail.com: -- type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5827 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Robert Kern robert.k...@gmail.com added the comment: James McIlree from Apple has informed me on dtrace-discuss that ustack helpers cannot currently be built on OS X. Bummer. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3565] array documentation, method names not 3.0 compliant
Martin v. Löwis mar...@v.loewis.de added the comment: I think this patch is unacceptable for Python 3.1. It is an incompatible change (removing a method), one would have to deprecate the method to be removed first. I also agree with Benjamin that a wider-audience approval of the deprecation would be required. I, myself, remain opposed to this change. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3565 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3565] array documentation, method names not 3.0 compliant
Matt Giuca matt.gi...@gmail.com added the comment: I agree with that -- too big a change to make now. But can we please get the documentation patch accepted? It's been waiting here for eight months with corrections to clearly-incorrect documentation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3565 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
