Barry A. Warsaw added the comment:
On Aug 18, 2011, at 03:58 PM, STINNER Victor wrote:
>
>STINNER Victor added the comment:
>
>> I'm just suggesting one more special case for linux*
>
>You suggest to have a special case in Python 2.7 and 3.2, but not in Python
>3
Barry A. Warsaw added the comment:
On Aug 18, 2011, at 05:54 PM, Martin v. Löwis wrote:
>As for the cases where "linux3" is reported: I don't care that
>they break. Python 2.6 and Python 2.7.2 is incompatible with
>Linux 3. Users should be advised to a) not u
Barry A. Warsaw added the comment:
On Aug 19, 2011, at 02:23 PM, STINNER Victor wrote:
>(2) Python 3.3: change sys.platform to 'linux'? Votes:
>
>Martin v. Löwis: +1
>Charles-François Natali: -1
>Amaury Forgeot d'Arc: -1
>Antoine Pitrou: -0 ?
>Victor Stinner
Barry A. Warsaw added the comment:
Seems reasonable to me. When did/does unicodedata ever have a __file__
attribute?
--
___
Python tracker
<http://bugs.python.org/issue12
Barry A. Warsaw added the comment:
I think it should be deprecated and eventually removed. I don't remember why I
put it in this file, and besides Mailman 3 won't use it.
--
___
Python tracker
<http://bugs.python.o
Barry A. Warsaw added the comment:
On Aug 18, 2011, at 07:09 AM, Nick Coghlan wrote:
>I'm not sure this is 100% fixed. After dist-upgrading the Kubuntu VM on my
>netbook and updating to the latest Py3k code, I got a lot of test errors,
>even after a make distclean and ./confi
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue6715>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue12850>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
I tend to agree that the errno is much less useful than the symbolic name. The
former is useful and will be available as an attribute, but the latter should
be used in the str. The change will probably break scads of doctests, but is
probably worth it
Changes by Barry A. Warsaw :
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue8409>
___
___
Python-bugs-
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue12942>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
Patch accepted, please apply for 2.6.6.
--
resolution: -> accepted
___
Python tracker
<http://bugs.python.org/iss
Changes by Barry A. Warsaw :
--
priority: normal -> release blocker
versions: +Python 2.6 -Python 2.7, Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/iss
Barry A. Warsaw added the comment:
I'm putting this one in the same category as bug 7467. I think these two, plus
the patches which were applied to release26-maint after rc1 (without approval
;) will require an rc2. If that can be worked out schedule-wise, I'll allow
these pat
Barry A. Warsaw added the comment:
The fix for this was applied after 2.6.6rc1, and it wasn't approved by me. Is
it critical for 2.6? Is it a regression since 2.6.5? The way I see it, we
either back this out or release an rc2. There may be other reasons to release
an rc2, but I ne
Changes by Barry A. Warsaw :
--
priority: normal -> release blocker
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue2944>
___
___
Pyth
Barry A. Warsaw added the comment:
Why was this merged to 2.6 after 2.6.6rc1 without approval?
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue1285
Changes by Barry A. Warsaw :
--
priority: low -> release blocker
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue1285086>
___
___
Pyth
Barry A. Warsaw added the comment:
flox reverted in r83967 for 2.6.6.
--
priority: release blocker ->
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
Barry A. Warsaw added the comment:
I agree w/mvl. Giampaolo, please revert this for 2.6.6.
--
___
Python tracker
<http://bugs.python.org/issue2944>
___
___
Pytho
Barry A. Warsaw added the comment:
Since the patch only changes a test, and it looks innocent enough (i.e. no
possibility of regression), and it only changes a test that is run with -u all,
I will allow this for 2.6.6.
Mark, please apply your test_curses_getmouse.patch. You can then close
Barry A. Warsaw added the comment:
After chatting with __ap__ on irc, i'm going to reject this patch for 2.6.6.
--
nosy: +barry
priority: release blocker ->
status: open -> closed
___
Python tracker
<http://bugs.python
Barry A. Warsaw added the comment:
Just to close the loop: thanks for reverting this for 2.6.6!
--
___
Python tracker
<http://bugs.python.org/issue2944>
___
___
Barry A. Warsaw added the comment:
Thanks guys. I'll allow this in for 2.6.6 if you can commit it before Sunday
8/15. I'd like the buildbots to have plenty of time to turn green before
schedule release on Monday. Please include a NEWS item and close this issue
once it's
Barry A. Warsaw added the comment:
This is a regression introduced in 2.6.6rc1. After discussion in irc with
merwok, it is agreed that he will revert to pre-2.6.6rc1 behavior and not apply
any fix. It's way too late to be changing behavior in 2.6.6. Folks using
Python 2.6 will just
Barry A. Warsaw added the comment:
Please upload a patch specifically for 2.6.6 finally so that I can review it
(and test it locally). It *seems* safe enough so if you and I both have a high
confidence it won't regress anything, and it can go in before Monday, then I
might approve i
Barry A. Warsaw added the comment:
Looks okay to me on *nix. You can check this in as long as test -u all passes
on Windows. Please include a NEWS file entry and close this issue when it's
committed. Thanks!
--
resolution: ->
Barry A. Warsaw added the comment:
The one thing that looks weird to me is VRFY. Since it never actually does
verify the user, should we even claim to support the command? Why not let
subclasses claim support if they want to add it
Barry A. Warsaw added the comment:
Guido has spoken:
http://mail.python.org/pipermail/python-dev/2010-August/103104.html
We'll keep the change for 2.6.6rc2.
--
nosy: +barry
status: open -> closed
___
Python tracker
<http://bugs
Barry A. Warsaw added the comment:
r84103 in release26-maint
I will let Ronald commit to the other branches. I did this one due to the
timing of 2.6.6 rc 2. Bumping status away from release blocker.
--
priority: release blocker -> h
Barry A. Warsaw added the comment:
I think it's too late to try to get this into 2.6.6. rc2's already been
released, I don't expect/want an rc3, and I'm not comfortable changing this at
this point. Unless you can convince me it's absolutely critical, I won&
Changes by Barry A. Warsaw :
Removed file: http://bugs.python.org/file17895/preview.diff
___
Python tracker
<http://bugs.python.org/issue9193>
___
___
Python-bugs-list m
Changes by Barry A. Warsaw :
Removed file: http://bugs.python.org/file17972/2010-07-12.txt
___
Python tracker
<http://bugs.python.org/issue9193>
___
___
Python-bugs-list m
Changes by Barry A. Warsaw :
Removed file: http://bugs.python.org/file18125/diff.txt
___
Python tracker
<http://bugs.python.org/issue9193>
___
___
Python-bugs-list mailin
Changes by Barry A. Warsaw :
--
title: Versioned .so files -> PEP 3149 (versioned .so files) reference
implementation
Added file: http://bugs.python.org/file18558/pep3149.txt
___
Python tracker
<http://bugs.python.org/iss
Changes by Barry A. Warsaw :
--
resolution: -> accepted
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Barry A. Warsaw added the comment:
What platform/OS is this happening on? I've tested the PEP 3149 patch on
various Ubuntu, OS X, and Debian systems and never needed this. Not saying
it's a bad patch, I just think there's something else environmental going on
that I nev
Barry A. Warsaw added the comment:
I guess I'm concerned about any compatibility issues e.g. an extension built
for 3.1 trying to load into 3.2. But that'll probably fail anyway. So I guess
it's impossible to build a bare .so extension
Barry A. Warsaw added the comment:
Amaury, you mention a sys.build_config dictionary, but I think it should
actually be baked into the sysconfig module, possibly as a _sysconfig extension
module. sysconfig is the new goodness for getting at this, and I don't think
it ought to have
Barry A. Warsaw added the comment:
@dmalcolm: I suspect you can reduce your diff for Python 3.2 now that PEP 3149
has landed.
--
___
Python tracker
<http://bugs.python.org/issue9
Barry A. Warsaw added the comment:
@Amaury: yes, that makes perfect sense. With PEP 3149, a debug (or any
differently built) interpreter will pick up only the _sysconfig.blah.so that's
appropriate for it, so baking it into there, with public API exposure through
sysconfig seems lik
Barry A. Warsaw added the comment:
s/3179/3149/
:)
The point about building w/o distutils is a good one and touches on my concerns
in my comment above. It would be nice to know whether there's any measurable
practical benefit to the change, i.e. measure startup time for an applic
Barry A. Warsaw added the comment:
How is this different than overwriting pyc files, except that there's probably
less of a use case for pycs? IOW, if we were to do something about this, it
should probably be an option to ignore any existing pyc (or pyo if -O is used)
files and writ
Barry A. Warsaw added the comment:
My (I think fairly straightforward) idea is to just compile the useful values
in Makefile and config.h into _sysconfig.c and arrange for sysconfig to import
that and check it first (fallback to parsing mf and conf.h).
I'll see if I can whip up a patc
Barry A. Warsaw added the comment:
Uh, duh. Thanks for reminding me about that Arfrever! :) That should be
everything Toshio needs I think. Plus this request is 4 years old.
Closing as won't fix.
--
resolution: -> wont fix
status: open -
Barry A. Warsaw added the comment:
Thanks Toshio, I get it now. I think pre-generating the proper pyo's is
probably the best solution.
--
___
Python tracker
<http://bugs.python.org/issu
Barry A. Warsaw added the comment:
+1
--
___
Python tracker
<http://bugs.python.org/issue9864>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
@Martin: yep, I know we still need to install pyconfig.h and Makefile, but we
shouldn't need to parse them to get programmatic access to the data they
contain.
--
___
Python tracker
<http://bugs.py
Changes by Barry A. Warsaw :
--
title: deriving configuration information for different builds with the same
prefix -> deriving configuration information for different builds with the same
prefix
___
Python tracker
<http://bugs.pyth
New submission from Barry A. Warsaw :
sysconfig.get_config_h_filename() returns the path of pyconfig.h. The Makefile
is also used to return values from sysconfig but it's path is hidden in a
non-public method, for no good reason that I can think of. Therefore,
sysc
Barry A. Warsaw added the comment:
I was thinking along the lines that RDM outlined, IOW that _sysconfig.c or
equivalent would be autogenerated at build time. But I think there are really
two issues here:
1) Avoiding parsing of pyconfig.h and Makefile to get variable values for the
New submission from Barry A. Warsaw :
This is splitting one concern from bug 9807 - specifically to avoid parsing
pyconfig.h and Makefile in the sysconfig module by autogenerating an extension
module (e.g. _sysconfig.c) at build time and using that to get the variables
from those two files
Barry A. Warsaw added the comment:
See issue 9878 for the "don't parse" bug.
--
___
Python tracker
<http://bugs.python.org/issue9807>
___
___
Pyt
Barry A. Warsaw added the comment:
See issue 9807
--
___
Python tracker
<http://bugs.python.org/issue9878>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
On Sep 16, 2010, at 06:15 PM, Benjamin Peterson wrote:
>-1 The Makefile is very implementation specific to CPython.
and pyconfig.h isn't?
-Barry
--
___
Python tracker
<http://bugs.python.or
Changes by Barry A. Warsaw :
--
keywords: +patch
Added file: http://bugs.python.org/file18903/9877.diff
___
Python tracker
<http://bugs.python.org/issue9
Barry A. Warsaw added the comment:
I don't agree that it's a bad thing that sysconfig exposes implementation
specific information - it seems kind of the point of it.
"The sysconfig module provides access to Python’s configuration information
like the list of installatio
Barry A. Warsaw added the comment:
Patch attached.
--
___
Python tracker
<http://bugs.python.org/issue9877>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
Added file: http://bugs.python.org/file18904/docs.diff
___
Python tracker
<http://bugs.python.org/issue9877>
___
___
Python-bugs-list mailin
Barry A. Warsaw added the comment:
On Sep 16, 2010, at 08:27 PM, Éric Araujo wrote:
>Éric Araujo added the comment:
>
>> I don't agree that it's a bad thing that sysconfig exposes
>> implementation specific information - it seems kind of the point of
>> it.
Barry A. Warsaw added the comment:
Note that I tried to reproduce this on my 10.04.1 system, with various states
of Python 2.7 installed, etc. and was unable to reproduce it. It's certainly
odd that you're getting the SystemError on
Changes by Barry A. Warsaw :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue9877>
___
___
Python-bugs-list mailing list
Unsubscri
Barry A. Warsaw added the comment:
On Sep 18, 2010, at 12:23 PM, Antoine Pitrou wrote:
>Antoine Pitrou added the comment:
>
>Barry's request looks reasonable. Any build information will have
>platform specificities to it.
Thanks. I'll take that as approval to land it.
Barry A. Warsaw added the comment:
r84925
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue9877>
___
___
Pyth
Barry A. Warsaw added the comment:
It does make sense, and email6 is like Python 3 in the sense that backward
compatibility is not a priority.
--
___
Python tracker
<http://bugs.python.org/issue9
New submission from Barry A. Warsaw :
According to this message, Python's errno module is missing some symbols:
https://lists.ubuntu.com/archives/ubuntu-devel/2010-August/031341.html
ENOMEDIUM 123 /* No medium found */
EMEDIUMTYPE 124 /* Wrong medium type */
ECAN
Barry A. Warsaw added the comment:
r84966
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue9916>
___
___
Pyth
Barry A. Warsaw added the comment:
Certainly at a minimum, the docs should describe the exception and workaround
instead of just:
"setlocale() is not thread safe on most systems. Applications typically start
with a call of
import locale
locale.setlocale(locale.LC_ALL, '&#x
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue1615376>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue1652>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
I have a some code available for review here:
http://codereview.appspot.com/2340041/
I've actually gone down a farther path than I originally intended, but I do
kind of like where this is heading. It will allow me to install different
Python builds o
Barry A. Warsaw added the comment:
dmalcom and doko remind me that we need to handle the .so when --enable-shared
is included
--
___
Python tracker
<http://bugs.python.org/issue9
Barry A. Warsaw added the comment:
so -Wl,-h is what counts [17:48]
barry: and it would be good to have this soname available in this new
module too [17:49]
--
___
Python tracker
<http://bugs.python.org/issue9
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue9841>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
bzr branch lp:~barry/python/issue9807
https://code.edge.launchpad.net/~barry/python/issue9807
--
___
Python tracker
<http://bugs.python.org/issue9
Barry A. Warsaw added the comment:
RDM, I wonder if it wouldn't be better (in email6) to use an instance to
represent the 3-tuple instead? It might make for clearer client code, and
would allow you to default things you might generally not care about. E.g.
class NonASCIIParameter:
Barry A. Warsaw added the comment:
In email6, can we at least make tuple returning methods return namedtuples
instead?
--
___
Python tracker
<http://bugs.python.org/issue6
Barry A. Warsaw added the comment:
I agree that it makes sense to have consistent types in the output. As for
whether to add a new method or fix the existing one, I'm a bit torn, but I'd
probably opt for fixing the existing function rather than adding a new one,
just because I t
Barry A. Warsaw added the comment:
>The point of a new method is to return the header as a human-readable
>string, rather than a list of tuples. It has added value besides
>leaving the old method alone ;)
+1 then! :)
--
___
Python track
New submission from Barry A. Warsaw :
Running the test suite on py3k r85440, I get the following failure:
==
ERROR: test_getproxies_environment_keep_no_proxies (__main__.ProxyTests
Barry A. Warsaw added the comment:
Looks good to me.
--
nosy: +barry
resolution: -> accepted
___
Python tracker
<http://bugs.python.org/issue10103>
___
___
Py
Barry A. Warsaw added the comment:
This may not be a Python bug.
The failure is consistent on all Ubuntu 10.10 machines I've tried, including
both i386 and x86_64 platforms. I've gone back many svn revisions and even
pulled down earlier alpha tarballs and the failure is consist
Barry A. Warsaw added the comment:
Senthil, can you provide any additional information on where/when you've seen
this? AFAICT, test_urllib.py is the only test it shows up, but it's totally
consistent. What OS/platforms have you seen this happen on? Same test or
dif
Changes by Barry A. Warsaw :
--
title: test_urllib.py fails in py3k r85440 with RuntimeError -> test_urllib.py
fails with RuntimeError on Ubuntu 10.10
___
Python tracker
<http://bugs.python.org/issu
Barry A. Warsaw added the comment:
The problem occurs on Ubuntu 10.10 because there's a new environment variable
called $UBUNTU_MENUPROXY in the default user environment. This is why it
suddenly showed up in Python 3.1 and why it does not occur on other OS (even
Ubuntu
Changes by Barry A. Warsaw :
--
versions: +Python 3.1
___
Python tracker
<http://bugs.python.org/issue10094>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10094>
___
___
Python-bugs-list
Barry A. Warsaw added the comment:
Let's try splitting this issue into separate patches. This first one just
exposes the ABI flags in the sys module and in the python-config script. It
doesn't change any installation behavior.
http://codereview.appspot.c
Barry A. Warsaw added the comment:
I'm afraid this can't be fixed in 2.6.
--
versions: -3rd party, Python 2.6
___
Python tracker
<http://bugs.python.
Barry A. Warsaw added the comment:
Interestingly enough, the distutils failure that dmalcolm found was present in
the trunk even before my patch. If you build Python with --enable-shared, that
distutils test fails because of the default path used for the -L option. I
fixed that in my patch
Barry A. Warsaw added the comment:
I fixed this in py3k branch, so you just need to backport that. I can do if
you can't get to it in the next day or so.
--
___
Python tracker
<http://bugs.python.org/is
Barry A. Warsaw added the comment:
Hi Eric, yes, that's basically what I did. See _fix_command(), which *should*
be the only thing that needs to be backported. I do believe it's a faulty test
and hopefully the comment explains why it's necessary.
Thanks for giving the
Barry A. Warsaw added the comment:
Even though this one's older, I'm going to mark it as a duplicate of issue
10126, which is tracking the backport of the fix I made in Python 3.2 to 3.1
and 2.7.
The key issues here are that Python was built with --enabled-shared and the
test *o
Barry A. Warsaw added the comment:
Seems like roundup hates me. Just go to issue 10126.
--
___
Python tracker
<http://bugs.python.org/issue9539>
___
___
Pytho
Barry A. Warsaw added the comment:
Here now is the second half of the patch, which installs the binary, library,
and includes into names with abiflags. I understand this is more
controversial, but it will help continue the discussion.
--
Added file: http://bugs.python.org/file19272
Barry A. Warsaw added the comment:
Hi Éric, what's the status on the backport?
--
___
Python tracker
<http://bugs.python.org/issue10126>
___
___
Pytho
Barry A. Warsaw added the comment:
It's possible the proposed patch for 2.7 should be used in python 3 also. Or
as __ap__ suggestions in irc, os.path.dirname(sys.executable)
--
Added file: http://bugs.python.org/file19328/10126-py27.txt
___
P
Barry A. Warsaw added the comment:
Fixed in 2.7 by r85784
--
___
Python tracker
<http://bugs.python.org/issue10126>
___
___
Python-bugs-list mailing list
Unsub
Changes by Barry A. Warsaw :
--
assignee: eric.araujo -> barry
___
Python tracker
<http://bugs.python.org/issue10126>
___
___
Python-bugs-list mailing list
Un
Barry A. Warsaw added the comment:
I believe all known failures in 2.7, 3.1, and 3.2 both with and without
--enable-shared are now fixed. Let's see what the buildbots say.
--
resolution: -> fixed
status: open -> closed
___
Python tra
501 - 600 of 2726 matches
Mail list logo
