Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue46142>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue46090>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
I think it does a better service to users to explain how Python returns None
implicitly if a function doesn't have any other explicit return value. If the
print() docs had this note, it would be confusing why other similar functions
don't.
Barry A. Warsaw added the comment:
> Barry: The PEP 8 'return None' recommendation could be added to the Reference
> entry for 'return'. But I think this should be a separate issue as 1) it is
> about coding rather than documentation and 2) there is the possib
Barry A. Warsaw added the comment:
I've never personally needed this, but I could see where it could come in handy.
I wonder if __iter__() would be the right API for that? I wonder then if we
should also implement __contains__()?
Would you be interested in creating a PR for the fe
Barry A. Warsaw added the comment:
I think you’re right that the iterator API isn’t very helpful. I also agree
that you probably really want to answer the “why identifiers are in this
template?” question. As for repeats, there’s two ways to think about it. You
could return all the
Barry A. Warsaw added the comment:
As Dennis points out, this is not a bug, it's already valid Python syntax.
--
nosy: +barry
resolution: -> not a bug
status: pending -> open
___
Python tracker
<https://bugs.python.
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue46328>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
sys.exception() seems like a decent enough trade-off. I've always disliked the
abbreviations in "exc_info". It doesn't feel big enough for a PEP to me.
--
___
Python tracker
<https://bug
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue46330>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
What are the (unoptimized) performance implications of replacing one
instruction with multiple instructions?
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue46
Barry A. Warsaw added the comment:
Very interesting. Do we have any current (or even cutting edge, i.e. 3.11)
timings for individual instructions? Or a breakdown of how frequently
different instructions are invoked? I remember Carl Shapiro presenting his
findings here several years ago
Barry A. Warsaw added the comment:
IIRC, Carl got a lot of benefit out of reordering the opcodes in the main loop
to put the most common ones at the top. I don't know if that is still relevant
or whether computed gotos, when enabled, change that cal
Barry A. Warsaw added the comment:
> Usually the calling function object should be enough.
I want to at least provide some historical context on why sys._getframe()
exists. I originally wrote that to support PEP 292 and internationalization in
Mailman. This has since been extracted i
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue46896>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
I believe this is because string_find_internal() uses an O& with
_PyEval_SliceIndex() to convert its start and end arguments, but the
latter function does not accept None. To fix this, you'd have to change
string_find_internal() to do its own argument
Barry A. Warsaw added the comment:
facundo, robert and i looked at this patch and it seems okay.
suggestions: document the reference count semantics of
_ParseTupleFinds() and include a definition of that function in a .h
file. since its non-public, maybe find.h is the right place to put it
Barry A. Warsaw added the comment:
On Sep 12, 2011, at 12:34 PM, Nick Coghlan wrote:
>It wouldn't surprise me at all if the laptop's links were a little off - I
>started with a Kubuntu image off VMWare's site quite some time ago, then
>dist-upgraded it through a couple
Barry A. Warsaw added the comment:
Suman, good eye, confirmed! Thanks for the patch, I'll commit this to 3.2 and
3.3.
--
assignee: -> barry
___
Python tracker
<http://bugs.python.org
Changes by Barry A. Warsaw :
--
title: Resource is not released before returning from the functiion -> Resource
is not released before returning from the function
___
Python tracker
<http://bugs.python.org/issu
Changes by Barry A. Warsaw :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue13021>
___
___
Python-bugs-list
Barry A. Warsaw added the comment:
Note that Python 2.6 is also vulnerable to the crash. While we do not have an
exploit, we did get a report on security@ which led to this bug. I could be
convinced to allow the patch to 2.6 on grounds that if the crasher can be
exploited, better to apply
Changes by Barry A. Warsaw :
--
versions: -Python 3.1
___
Python tracker
<http://bugs.python.org/issue7732>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
On Oct 04, 2011, at 01:03 PM, Boštjan Mejak wrote:
>I have a better idea... Why don't we change the "linux2" string into just
>"linux". That way we will never run into this kind of issue, even in the
>future when Linux kerne
New submission from Barry A. Warsaw :
Initial results from warsaw-ubuntu-arm buildbot indicates two failures in
test_socket.py
==
ERROR: test_create_connection_timeout
(test.test_socket.NetworkConnectionNoServer
Changes by Barry A. Warsaw :
--
versions: +Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue13110>
___
___
Python-bugs-list mailin
Barry A. Warsaw added the comment:
This appears to be the problem:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/868812
I'm going to close this Python bug since it seems to be related to the Linux
kernel on armel. Editing the /etc/hosts file gets around the problem and lets
the
Barry A. Warsaw added the comment:
Was this patch ever folded into Python 3.2? Looking at the hg repository, I
think the answer is "no". It does appear to have made it into Python 2.7 and
trunk though (afaict).
In point of fact, this bug is hitting me now with 3.2.2.
-
Changes by Barry A. Warsaw :
--
assignee: -> barry
___
Python tracker
<http://bugs.python.org/issue11250>
___
___
Python-bugs-list mailing list
Unsubscri
Barry A. Warsaw added the comment:
I also noticed that test_parser.py isn't being run in either 3.2 or 3.3. I'll
fix that at the same time I port this patch to 3.2.
--
___
Python tracker
<http://bugs.python.o
Barry A. Warsaw added the comment:
Okay, re-enabling test_parser.py introduces a number of test failures in
test_all_project_files(). Because I don't want to continue to shave the yak on
this one, I'm going to wrap this test in @expectedFailure and open a separate
Barry A. Warsaw added the comment:
It would be nice if expectedFailure took a bug number and printed a url to the
tracker.
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue12
New submission from Barry A. Warsaw :
In working on issue 11250, I noticed that lib2to3's test_parser.py tests were
not enabled. Fixing that was easy enough, but then test_all_project_files() in
TestParserIdempotency began failing. I've shaved enough yaks for the day so I
am goin
Changes by Barry A. Warsaw :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue11250>
___
___
Python-bugs-list mailing list
Unsubscri
Barry A. Warsaw added the comment:
I'll just mention that the elimination of bytes handling is a bit unfortunate,
since this idiom which works in Python 2 no longer works:
fp = urlopen(url)
json_data = json.load(fp)
/me sad
--
nosy: +
Barry A. Warsaw added the comment:
On Oct 13, 2011, at 04:01 PM, Éric Araujo wrote:
>The PEP 376 implementation in packaging.database has been called ugly and
>opaque. When discussing PEP 396 for example (that’s why I’m adding Barry and
>Antoine to nosy, for their feedback),
>get_
Barry A. Warsaw added the comment:
Note that I think it's best to fix the underlying failures rather than silence
them. ;)
--
___
Python tracker
<http://bugs.python.org/is
Barry A. Warsaw added the comment:
On Oct 21, 2011, at 06:35 PM, Benjamin Peterson wrote:
>Benjamin Peterson added the comment:
>
>Or perhaps we don't need joke backward compatibility? (That's nearly 3 years
>old.)
OTOH, __future__ imports (even jokes) s
Barry A. Warsaw added the comment:
On Oct 21, 2011, at 07:33 PM, Antoine Pitrou wrote:
>Antoine Pitrou added the comment:
>
>> OTOH, __future__ imports (even jokes) should never be removed.
>
>But their meaning can be altered?
>(as part of another joke if you want :)
We
Barry A. Warsaw added the comment:
Still investigating, but FTR, this isn't technically an Ubuntu issue as much as
it is a Debian issue (and thus inherited by Ubuntu). I can reproduce the
failure in Python 3.3 on Debian Wheezy.
--
___
P
Changes by Barry A. Warsaw :
--
title: test_ssl failures on Ubuntu 11.10 -> test_ssl failures on Debian/Ubuntu
___
Python tracker
<http://bugs.python.org/issu
Barry A. Warsaw added the comment:
TL;DR: Let's rip out the false assumption that an SSLv23 client cannot connect
to an SSLv3/TLSv1 server.
I now believe this is simply an erroneous assumption on the part of the Python
test suite, namely that SSLv23 method clients cannot connect to SSL
Barry A. Warsaw added the comment:
On Oct 25, 2011, at 09:56 AM, Antoine Pitrou wrote:
>
>Antoine Pitrou added the comment:
>
>> It looks like it's been this way for a long time too.
>
>But tests have always passed here using OpenSSL 1.0.0.
Right, sorry, what I
Barry A. Warsaw added the comment:
I'm not sure I particularly like this patch, and I can't test it on anything
other than Debian/Ubuntu right now, but it does "fix" the test (defined as:
making it pass :).
AFAICT, there's no way to tell openssl to revert back to t
Barry A. Warsaw added the comment:
Here's the diff that disables SSLv2 and changes the expected sense of the
connection results. Again, I can't test this on other than Debian/Ubuntu atm,
so feedback would be useful.
--
Added file: http://bugs.python.org/file23518/
Barry A. Warsaw added the comment:
On further reflection, I don't much like my second patch either. I don't think
it'll be portable. I suggest just removing this test.
--
___
Python tracker
<http://bugs.pyt
Barry A. Warsaw added the comment:
On Oct 27, 2011, at 10:08 PM, Antoine Pitrou wrote:
>Antoine Pitrou added the comment:
>
>For the record, both patches work fine here (Mageia 1, OpenSSL 1.0.0d).
Cool. I'll try to verify them on OS X 10.6 (and maybe 10.7). If they work
the
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue13241>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
I can't test this on OS X 10.7 because of issue 13241 but it works fine on OS X
10.6.
I'm going to go with the first diff (i.e. the non-sense changing version). I
can't say why I favor that version but since you've both verified it work
Changes by Barry A. Warsaw :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue13218>
___
___
Python-bugs-list
Barry A. Warsaw added the comment:
When I need defaults, I make them part of the mapping that gets passed into
.substitute() and .safe_substitute(). It doesn't feel to me like it's
necessary to attach them to the Template instance. Also, couldn't you just
subclass string.
Barry A. Warsaw added the comment:
On Nov 29, 2011, at 12:50 PM, Éric Araujo wrote:
>Before you put more work into this, it would be nice to get confirmation from
>one import expert that the bug is valid: I know the import system only
>superficially, and I’m not sure that package/__i
Barry A. Warsaw added the comment:
Confirmed, and this is really annoying. I'm of the mind to apply your second
idea.
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/is
Barry A. Warsaw added the comment:
Sorry, I meant your first option.
--
___
Python tracker
<http://bugs.python.org/issue11147>
___
___
Python-bugs-list mailin
Changes by Barry A. Warsaw :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue11147>
___
___
Python-bugs-list
Barry A. Warsaw added the comment:
Fails in exactly the same way when built from my shell account using current hg
head. Does not fail on same version of OS on amd64.
--
___
Python tracker
<http://bugs.python.org/issue13
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue1294232>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue13508>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Barry A. Warsaw :
This is already publicly known and in deep discussion on python-dev. The
proper fix is still TBD. Essentially, hash collisions can be exploited to DoS
a web framework that automatically parses input forms into dictionaries.
Start here:
http
Barry A. Warsaw added the comment:
On Jan 03, 2012, at 08:24 PM, Antoine Pitrou wrote:
>I think on the contrary it must be enabled by default. Leaving security
>holes open is wrong.
Unless there's evidence of performance regressions or backward
incompatibiliti
Barry A. Warsaw added the comment:
On Jan 03, 2012, at 09:43 PM, Benjamin Peterson wrote:
>Barry, when this gets fixed, shall we coordinate release times?
Yes!
--
___
Python tracker
<http://bugs.python.org/issu
Barry A. Warsaw added the comment:
On Jan 04, 2012, at 07:30 AM, Raymond Hettinger wrote:
>Why is this listed as a release blocker? It is questionable whether it
>should be done at all? It is a very aggressive change.
It's a release blocker so that the issue won't get ig
Barry A. Warsaw added the comment:
On Jan 04, 2012, at 06:00 AM, Paul McMillan wrote:
>Developers would be startled to find that ordering stays consistent on a 64
>bit build but varies on 32 bit builds.
Well, one positive outcome of this issue is that users will finally viscerally
unde
New submission from Barry A. Warsaw :
The lexical analysis documentation says this:
http://docs.python.org/py3k/reference/lexical_analysis.html?highlight=raw%20bytes
"Bytes literals are always prefixed with 'b' or 'B';..."
"Both string and bytes literal
Barry A. Warsaw added the comment:
On Jan 09, 2012, at 03:15 PM, Antoine Pitrou wrote:
>
>Antoine Pitrou added the comment:
>
>> Either Python should accept both spellings
>
>+1. Been annoyed several times by this.
The $64k question: is this a
Barry A. Warsaw added the comment:
On Jan 09, 2012, at 03:35 PM, Antoine Pitrou wrote:
>
>Antoine Pitrou added the comment:
>
>> The $64k question: is this a new feature or a bug? :)
>
>Most certainly a feature...
In that case, since we can only add the new prefixes to
Barry A. Warsaw added the comment:
On Jan 09, 2012, at 07:27 PM, Antoine Pitrou wrote:
>Updated patch with doc.
Nicely done. +1
--
___
Python tracker
<http://bugs.python.org/issu
Changes by Barry A. Warsaw :
--
resolution: -> duplicate
status: open -> closed
superseder: -> Building Python on multiarch Debian and Ubuntu
___
Python tracker
<http://bugs.python.or
Barry A. Warsaw added the comment:
Given that 2.6.7 is rc2 with a final release scheduled in 2 days, I don't want
to apply this to 2.6 right now. Can you guarantee this won't regress for
anybody? If so, then I'm also +0 for 2.6 after th
New submission from Barry A. Warsaw :
I'm making this a release blocker for 2.7.2 because I want to ensure that the
change is deliberate and appropriate. This is triggered by a bug report in
Ubuntu where the change in behavior was noticed:
https://bugs.launchpad.net/nova/+bug/791221/+
Barry A. Warsaw added the comment:
Using sorted() makes sense to me.
Note that I've at least accomplished one goal, which is to have a tracker issue
that discusses the merits of the change. That way, no matter what the RM
decides, I can at least point to an issue for justification w
Changes by Barry A. Warsaw :
--
nosy: +georg.brandl
priority: normal -> release blocker
___
Python tracker
<http://bugs.python.org/issue12291>
___
___
Python-
Barry A. Warsaw added the comment:
Raymond, I like your patch and I think it addresses the issue nicely. I made
one small change, which is to add a test for non-list-sequenceness instead of
changing the existing __dir__is_list test. I think both tests are useful to
keep.
Benjamin, what do
New submission from Barry A. Warsaw :
I have both a setup.py and a setup.cfg in my package. I wanted to use `pysetup
create` to add the new packaging stanzas to my setup.cfg, but instead, pysetup
clobbered everything. I think it should instead append (or prepend) the new
stuff to the
Barry A. Warsaw added the comment:
Nice to see my search didn't find this bug. ;)
I already committed a change to install packaging, but you may want to revert
that and commit the patch in this issue. I'll leave that for you to decide!
--
no
Barry A. Warsaw added the comment:
On Jun 15, 2011, at 02:04 PM, Éric Araujo wrote:
>Well, create is not update :) In its current form, create will save an
>existing setup.cfg as setup.cfg.old and generate a new one. The human
>operator will then have to merge both files if
Barry A. Warsaw added the comment:
That work around seems ugly. Why not back port the fix? It doesn't seem like
it could break anything and it's not even arguably a new feature, right?
--
nosy: +barry
___
Python tracker
<http://bu
Barry A. Warsaw added the comment:
Ah okay, I didn't see that in the changeset.
--
___
Python tracker
<http://bugs.python.org/issue12370>
___
___
Pytho
Barry A. Warsaw added the comment:
I think we should apply this to earlier applicable versions too. I would
accept this change for Python 2.6.
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue12
Barry A. Warsaw added the comment:
Thanks Benjamin!
--
___
Python tracker
<http://bugs.python.org/issue12417>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
I don't know that anybody relies on the current behavior and computers are now
a bazillion times faster than they were in 2004, so who needs that micro
optimization any more?
--
___
Python tracker
Barry A. Warsaw added the comment:
I'm running into this while trying to backport Python 2.7.2 to Ubuntu 10.04.
Our build machines are throwing an error because they catch the implicit cast
so as to prevent problems on ia64 and amd64.
http://wiki.debian.org/IMplicitPointerConversio
Changes by Barry A. Warsaw :
--
assignee: -> barry
___
Python tracker
<http://bugs.python.org/issue10309>
___
___
Python-bugs-list mailing list
Unsubscri
Barry A. Warsaw added the comment:
Python 3.1 is in security only mode, so this patch cannot be applied to that
version.
--
versions: +Python 3.3 -Python 3.1
___
Python tracker
<http://bugs.python.org/issue10
Changes by Barry A. Warsaw :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10309>
___
___
Python-bugs-list
Barry A. Warsaw added the comment:
I think this is also a regression in Python 2.7, as reported here:
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/813295
--
nosy: +barry
versions: +Python 2.7
___
Python tracker
<http://bugs.python.
Barry A. Warsaw added the comment:
Re-opening, as I think this needs to still be applied to Python 2.7.
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/issu
Barry A. Warsaw added the comment:
Never mind. This changeset got applied to 2.7 (thanks!) but didn't get linked
in the tracker.
changeset: 71523:b66bbbdc7abd
branch: 2.7
parent: 71518:73ae3729b8fe
user:Senthil Kumaran
date:Wed Jul 27 09:37:17 2011 +0800
su
Barry A. Warsaw added the comment:
As I just mentioned on python-dev (via Gmane), I'm uncomfortable with moving
the documentation for test.support into the devguide.
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/is
New submission from Barry A. Warsaw :
I found this out while experimenting with enum types that inherit from int.
The json library provides for extending the encoder to handle non-basic types;
in those cases, your class's .default() method is called. However, it is
impossible to ove
Barry A. Warsaw added the comment:
A cheap way of fixing this would be to test for str-ness of localename and if
it's a unicode, just localname.encode('ascii')
Or is that completely insane?
--
nosy: +barry
___
Python
Barry A. Warsaw added the comment:
For example:
diff -r fb49394f75ed Lib/locale.py
--- a/Lib/locale.py Mon Aug 15 14:24:15 2011 +0300
+++ b/Lib/locale.py Mon Aug 15 16:47:23 2011 -0400
@@ -355,6 +355,8 @@
"""
# Normalize the locale name and extract the e
Changes by Barry A. Warsaw :
--
keywords: +patch
Added file: http://bugs.python.org/file22904/issue12752.diff
___
Python tracker
<http://bugs.python.org/issue12
Changes by Barry A. Warsaw :
--
assignee: -> barry
___
Python tracker
<http://bugs.python.org/issue12752>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Barry A. Warsaw :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue12752>
___
___
Python-bugs-list
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue12326>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
@Sandro:
>> FTR, for Debian and derivatives, doko chose to use 'linux2' when building on
>> linux3.
>Luckily that has just been reverted.
No, I don't think it has:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633015
On
Barry A. Warsaw added the comment:
On Aug 16, 2011, at 02:28 PM, Sandro Tosi wrote:
>that's because you're on wheezy, that has 2.7.2-3, while the version
>which has the change reverted is -4 (still not transition to testing,
>since outdated on kbsd-i386)
I think it's b
Barry A. Warsaw added the comment:
On Aug 18, 2011, at 01:20 AM, James Y Knight wrote:
>James Y Knight added the comment:
>
>> I will backport the fix to 2.7 and 3.2.
>
>Uh, wait, so does that mean you're *not* going to do the
>compatibility-preserving thing and
Barry A. Warsaw added the comment:
On Aug 18, 2011, at 01:15 PM, Charles-François Natali wrote:
>Charles-François Natali added the comment:
>
>> My question too! I would say that stable releases should probably not get
>> this change, but should force sys.platform to lin
1 - 100 of 2273 matches
Mail list logo
