On Wed, 06 Jul 2011 01:23:55 +0900
"Stephen J. Turnbull" wrote:
> Antoine Pitrou writes:
>
> > I sincerely hope we don't start using the word "professional" to denote
> > "careful" or "good quality".
>
> No, by "profes
On Wed, 06 Jul 2011 09:13:58 +0200
Stefan Behnel wrote:
>
> > those who are interested can sign up to the diversity list and read/post to
> > the original thread here:
> >
> > http://mail.python.org/mailman/private/diversity/2011-July/002509.html
>
> Speaking of "singling out", I've been wonderi
On Thu, 7 Jul 2011 06:53:50 + (UTC)
Vinay Sajip wrote:
> Benjamin Peterson python.org> writes:
>
> >
> > 2011/7/6 Nick Coghlan gmail.com>:
>
> > > The API of the resulting object is the same (i.e. they're file-like
> > > objects). The behavioural differences are due to cases where the
> >
On Thu, 07 Jul 2011 10:07:38 +0200
"M.-A. Lemburg" wrote:
>
> That said, I'm not really up for a longer discussion on this. We've
> already had the discussion and decided against removing those
> parts of the codec API.
I don't remember any such decision. We decided against unilateraly
removing
On Thu, 7 Jul 2011 22:08:45 +1000
Nick Coghlan wrote:
> Currently, nobody has stepped forward to do the work of maintaining
> the codecs IO implementation independently of the io module, so the
> only two options seriously on the table are B and C.
Since nobody has stepped up to implement option
Hello,
Just a quick note that I have a working PEP 3151 implementation at
http://hg.python.org/features/pep-3151/, in named branch "pep-3151".
The implementation is (should be) complete on the feature side, so you
can play with it right now. It still lacks a deprecation mechanism for
old names.
On Sun, 17 Jul 2011 00:59:17 +1000
Nick Coghlan wrote:
>
> Exposing those flags would
> encourage people to do exactly that, and that would be a *really* bad
> idea
Making DNS resolution configurable (for example by allowing the user to
supply their own resolution function) in the stdlib's netwo
On Tue, 19 Jul 2011 16:00:57 +0100
Paul Moore wrote:
> On 19 July 2011 02:41, Vinay Sajip wrote:
> > The use of py from the command line is merely a convenience for developers
> > (as
> > the PEP says) - it's better to rely on shebang lines together with settings
> > in
> > the .ini to get the
On Tue, 19 Jul 2011 17:21:30 +0100
Paul Moore wrote:
>
> Two questions:
> 1. What level of support is there for PEP 397? If it's unlikely to get
> accepted, there's little point in basing a solution on it.
It only needs support from our Windows users or developers.
It is doubtful than any Linux
On Wed, 20 Jul 2011 14:12:42 -0400
Terry Reedy wrote:
> On 7/20/2011 11:41 AM, r.david.murray wrote:
>
> > diff --git a/Lib/email/utils.py b/Lib/email/utils.py
>
> > # We need wormarounds for bugs in these methods in older Pythons (see
> > below)
>
> Is 'wormaround' (variation of workaround)
On Thu, 21 Jul 2011 09:55:28 +1000
Mark Hammond wrote:
>
> > The two proposals
> > overlap but are not mutually exclusive. For future pythons, 'python33'
> > is easier to remember and type than 'py -v 3.3' or whatever the proposed
> > encantation is.
>
> 'py -3.3' - less chars to type than 'pyt
On Thu, 21 Jul 2011 15:37:01 -0700
Raymond Hettinger wrote:
> Please don't add the IRC link to the devguide.
>
> Based on conversations with Guido, he is against it being part of the core
> development process.
IRC is very much outside of the core development process, but it's
still a reasonable
On Tue, 19 Jul 2011 23:58:55 -0400
"P.J. Eby" wrote:
>
> Anyway, to make a long story short, we came up with an alternative
> implementation plan that actually solves some other problems besides
> the one that PEP 382 sets out to solve, and whose implementation a
> bit is easier to explain. (
Le vendredi 22 juillet 2011 à 09:53 +1000, Nick Coghlan a écrit :
> On Fri, Jul 22, 2011 at 9:35 AM, Antoine Pitrou wrote:
> > On Tue, 19 Jul 2011 23:58:55 -0400
> > "P.J. Eby" wrote:
> >>
> >> Anyway, to make a long story short, we came up with a
On Thu, 21 Jul 2011 17:31:04 -0700
Glenn Linderman wrote:
>
> If I have (on sys.path), a directory "x" containing a "y.py" module, and
> later (on sys.path), another directory "x" containing a "y.py" module,
> what is "from x import y" supposed to do?
>
> OR
>
> If I have (on sys.path), a mod
Le vendredi 22 juillet 2011 à 10:58 +1000, Nick Coghlan a écrit :
> On Fri, Jul 22, 2011 at 10:00 AM, Antoine Pitrou wrote:
> > Wouldn't it produce confusing situations like the above example?
>
> I don't see how it is any more confusing than any other form of
On Fri, 22 Jul 2011 21:29:23 +1200
Greg Ewing wrote:
>
> This whole episode seems to have resulted from a collision
> between two rather obscure things: that import statements
> involve locking things, and that some fairly innocuous
> looking calls, such as s.encode('ascii'), can trigger an
> imp
> >See http://bugs.python.org/issue9260
> >
> >There's a patch there but it needs additional sophistication to remove
> >deadlocks when doing concurrent circular imports.
>
> I don't think that approach can work, as PEP 302 loaders can
> currently assume the global import lock is being held when
On Sat, 23 Jul 2011 11:46:05 +0200
Charles-François Natali wrote:
> > Note that this commit wasn't actually a merge -- you'll have to use the
> > "hg merge" command for that.
>
> You're right.
> I guess that's what happens when I try to work past my usual bedtime ;-)
>
> By the way, I'm still g
On Sat, 23 Jul 2011 16:10:38 +0200
Charles-François Natali wrote:
>
> No traceback.
> Last time I did a push (yesterday), there was a slight difference, the
> lines reporting the failure were prefixed by "buildbot:" (IIRC). And
> indeed, none of my pushes triggers a build on the buildbots (and I'
On Sun, 24 Jul 2011 09:13:07 +1000
Ryan Kelly wrote:
>
> In latest trunk this optimisation seems to have gone away, the code is
> now:
>
> TARGET(BINARY_SUBSCR)
> w = POP();
> v = TOP();
> x = PyObject_GetItem(v, w);
> Py_DECREF(v);
>
Le dimanche 24 juillet 2011 à 03:15 +0300, Andrew Svetlov a écrit :
> You right. Sorry, I missed changes in ceval.c for py3k.
> Please note, simple test like:
>
> from timeit import timeit
>
> print('list', timeit("l[0]", "l = [1]"))
> print('tuple', timeit("l[0]", "l = (1,)"))
>
> Has results:
On Wed, 20 Jul 2011 01:53:09 -0500
Kerrick Staley wrote:
> On Mon, Jul 18, 2011 at 3:03 AM, Ned Deily wrote:
> > I think adding the requirement to mandate hard link vs soft link usage
> > is an unnecessary and unwarranted attempt at optimization. For
> > instance, IIRC, the OS X installers don't
On Sun, 24 Jul 2011 23:16:55 +0200
Antoine Pitrou wrote:
>
> I think the recommendation should be symbolic links for all systems.
> Hard links are generally harder to discover, while it is trivial to
> find out that a given file is a symbolink link, and to which other file.
> The
Hello,
> By the way, is it faster to not handle and than re-raise unwanted
> exceptions?
You mean "is it faster to not handle than re-raise unwanted
exceptions?". It probably is, yes.
> I don't understand how Antoine decided which errno should have an
> exception or not.
Mostly experience with
On Mon, 25 Jul 2011 15:28:47 +1000
Nick Coghlan wrote:
>
> > If we add EINTR, I don't know if it's better to add it to
> > BlockingIOError or to create a new exception (InterruptError?).
>
> InterruptedError seems like a reasonable candidate for addition to me
> - catch and retry in that case is
On Tue, 26 Jul 2011 15:20:55 +0200
Éric Araujo wrote:
> >
> > diff --git a/Lib/test/support.py b/Lib/test/support.py
> > --- a/Lib/test/support.py
> > +++ b/Lib/test/support.py
> > @@ -170,7 +170,7 @@
> > attribute = getattr(obj, name)
> > except AttributeError:
> > raise u
Le mardi 26 juillet 2011 à 10:56 -0500, Kerrick Staley a écrit :
> I'm indifferent either way. python3 is a hard link to python3.2, so I
> thought we'd make everything that way for consistency.
Is it? Yikes, I didn't know about that.
Regards
Antoine.
___
Ok, apparently the decision to make hard links for executables dates at
least back to:
changeset: 16221:588691f806f4
branch: legacy-trunk
user:Neil Schemenauer
date:Wed Jan 24 17:11:43 2001 +
files: Makefile.pre.in
description:
Flat makefile based on toplevel Mak
Hi,
> > But this i tell you - if i would be an italian.. then i.. would..
> > Viva la mamma - per que!!!
>
> Sob.
>
> This is **NOT** offensive against just anybody.
> (Except maybe that i don't take *myself* too seriously, because
> doing so is a bit strange on a planet which disappears in som
On Mon, 25 Jul 2011 15:28:47 +1000
Nick Coghlan wrote:
> There may be some error codes that we choose to map to these generic
> errors, even if we don't give them their own exception types at this
> point (e.g. ECONSHUTDOWN could map directly to ConnectionError).
Ok, I can find neither ECONSHUTDO
On Tue, 26 Jul 2011 19:32:56 -0400
Glyph Lefkowitz wrote:
>
> On Jul 26, 2011, at 6:49 PM, Antoine Pitrou wrote:
>
> > On Mon, 25 Jul 2011 15:28:47 +1000
> > Nick Coghlan wrote:
> >> There may be some error codes that we choose to map to these generic
> >
Some more digging indicates that ESHUTDOWN appears in asyncore with the
following commit:
changeset: 10934:c089020a7a1e
branch: legacy-trunk
user:Guido van Rossum
date:Tue Jun 08 13:20:05 1999 +
files: Lib/asynchat.py Lib/asyncore.py
description:
Sam's latest ver
On Wed, 27 Jul 2011 02:25:56 +0200
senthil.kumaran wrote:
>
> +def test_sites_no_connection_close(self):
> +# Some sites do not send Connection: close header.
> +# Verify that those work properly. (#issue12576)
> +
> +try:
> +with urllib.request.urlopen('h
On Wed, 27 Jul 2011 20:16:01 +0800
Senthil Kumaran wrote:
> On Wed, Jul 27, 2011 at 11:52:32AM +0200, Antoine Pitrou wrote:
> > > +
> > > +try:
> > > +with urllib.request.urlopen('http://www.imdb.com') as res:
> > > +
On Wed, 27 Jul 2011 16:14:40 +0300
Eli Bendersky wrote:
>
> Will it take long for newbie code to appear with the test.support version?
> Not to mention that grepping code that imports the "unlink" function
> directly doesn't reveal which one is being used.
>
> I think this is troublesome. I thin
On Wed, 27 Jul 2011 16:31:54 +0300
Eli Bendersky wrote:
>
> I wasn't aware of '%a' at all? It doesn't appear to be documented, and
> Python 2.6 doesn't support it:
>
> ValueError: unsupported format character 'a' (0x61) at index 1
>
> If it's new, it should at least be documented in library
Le mercredi 27 juillet 2011 à 16:54 +0300, Eli Bendersky a écrit :
>
> Thanks. I also saw this documented in the {!a} formatting
> documentation.
>
> Was it left out of the library/stdtypes doc on purpose (to encourage
> the new str.format), or is this an omission?
Certainly an omission.
Regard
On Wed, 27 Jul 2011 10:27:16 -0700
Brett Cannon wrote:
> >
> > Perhaps what we could do is move the documentation for test.support to
> > the devguide, and then vet the test suite so that unlink and friends
> > are always called as 'support.unlink', etc.
> >
>
> I like this solution since this is
On Wed, 27 Jul 2011 19:36:36 +0200
charles-francois.natali wrote:
>
> +- Issue #12603: Fix pydoc.synopsis() on files with non-negative st_mtime.
> +
Surely you mean non-positive? Non-negative st_mtime being the common
case.
Regards
Antoine.
___
Py
On Fri, 29 Jul 2011 14:35:19 +0200
eric.araujo wrote:
> http://hg.python.org/cpython/rev/97527f3f9829
> changeset: 71555:97527f3f9829
> branch: 3.2
> user:Éric Araujo
> date:Tue Jul 26 17:32:50 2011 +0200
> summary:
> Fix sorting or wording of some NEWS entries.
>
> I wo
On Fri, 29 Jul 2011 14:35:23 +0200
eric.araujo wrote:
>
> It is now possible to inherit from Thread and other classes, without
> having to import the private underscored names like multiprocessing did.
A correction: it was already possible to inherit from Thread (since
it's quite useful to do so
On Fri, 29 Jul 2011 14:35:24 +0200
eric.araujo wrote:
> http://hg.python.org/cpython/rev/bdad5bc9a2ed
> changeset: 71562:bdad5bc9a2ed
> branch: 3.2
> user:Éric Araujo
> date:Thu Jul 28 22:45:46 2011 +0200
> summary:
> Stop ignoring Mercurial merge conflits files (#12255).
On Fri, 29 Jul 2011 15:28:44 +0200
Éric Araujo wrote:
> Le 29/07/2011 14:50, Antoine Pitrou a écrit :
> >> changeset: 71562:bdad5bc9a2ed
> >> user:Éric Araujo
> >> summary:
> >> Stop ignoring Mercurial merge conflits files (#12255).
> >
On Fri, 29 Jul 2011 16:21:42 +0200
Éric Araujo wrote:
> > What use are these backups really? We are using a (D)VCS, you are not
> > losing anything.
>
> The .orig files after a revert could contain code that’s not committed
> anywhere. See also RDM’s reply to your message.
I would point out tha
On Fri, 29 Jul 2011 15:22:08 +0200
Éric Araujo wrote:
> >
> > There's no practical difference (from the user's point of view) between
> > extension modules and the library, so I think the "Extension Modules"
> > section should simply die.
>
> +1 to that. Would built-in modules like imp belong t
On Thu, 28 Jul 2011 11:28:43 +0200
Victor Stinner wrote:
>
> I will add your alternative to the PEP (except if you would like to do
> that yourself?). If I understood correctly, you propose to:
>
> * rename codecs.open() to codecs.open_stream()
> * change codecs.open() to reuse open() (and
On Fri, 29 Jul 2011 11:18:37 -0400
Barry Warsaw wrote:
>
> I'd much rather solve this problem by adding markup to functions that
> explicitly disclaim our normal backward compatibility guarantees. Squirreling
> away documentation for some parts of the stdlib seems similar to
> security-by-obscur
On Fri, 29 Jul 2011 11:51:18 -0400
Barry Warsaw wrote:
> On Jul 29, 2011, at 05:25 PM, Antoine Pitrou wrote:
>
> >> test.support *is* part of the stdlib.
> >
> >We have lots of internal APIs which are not documented, though.
> >And test.support *is* for internal
On Fri, 29 Jul 2011 12:19:45 -0400
"R. David Murray" wrote:
>
> > Besides, "hg status" is meant to show untracked files which could
> > *potentially* be tracked. It's not like anybody wants to track .orig
> > and .rej files, so having them in the ignore list is still the right
> > thing to do.
>
On Fri, 29 Jul 2011 13:34:13 -0700
Brett Cannon wrote:
> On Fri, Jul 29, 2011 at 13:16, Glyph Lefkowitz wrote:
>
> > On Jul 29, 2011, at 3:00 PM, Matt wrote:
> >
> > I don't see any real reason to drop a decent piece of code (HTMLParser,
> > that is) in favor of a third party library when only re
On Fri, 29 Jul 2011 18:47:07 -0400
Terry Reedy wrote:
>
> > And test.support *is* for internal use.
>
> No, the stuff in there is *not* for internal use within the module but
> for external use is possiby every test module.
I meant internal use for us. Really, whether or not it's
used cross-mo
On Fri, 29 Jul 2011 19:02:32 -0400
Terry Reedy wrote:
> On 7/29/2011 5:32 PM, Antoine Pitrou wrote:
> > On Fri, 29 Jul 2011 11:51:18 -0400
> > Barry Warsaw wrote:
> >> On Jul 29, 2011, at 05:25 PM, Antoine Pitrou wrote:
> >>
> >>>> test.support *
On Fri, 29 Jul 2011 22:22:05 -0400
"R. David Murray" wrote:
> On Fri, 29 Jul 2011 23:36:03 +0200, Antoine Pitrou
> wrote:
> > On Fri, 29 Jul 2011 12:19:45 -0400
> > "R. David Murray" wrote:
> > >
> > > > Besides, "hg status&qu
Hi Senthil,
> +if source_address: self.source_address = source_address
Could you try to follow PEP 8?
(I know PEP 8 is not always followed in old code, but there's no reason
not to follow it in code that we add to the stdlib)
> +SMTP.__init__(self, host, port, local_hostname = l
On Sat, 30 Jul 2011 09:25:27 -0400
Terry Reedy wrote:
> >
> > I'm sorry, can you be more precise. The effect of what?
>
> Your proposal to remove the current formatted documentation of
> test.support instead of completing it and force all developers to only
> have reference to the docstrings sc
Hi,
(I was asked to forward this from the bug tracker)
> We have also run into problems where a task tries to "return" (yield Return())
> from within a try: except Exception: block. Since returning from a coroutine
> is
> roughly equivalent to "raise GeneratorExit", the exception can be caught
Le dimanche 02 décembre 2007 à 12:08 -0800, Neal Norwitz a écrit :
> Note that StandardError was removed from py3k.
Out of curiosity, what is the reason for this? Another exception tree
rearrangement?
___
Python-Dev mailing list
Python-Dev@python.org
Le dimanche 02 décembre 2007 à 11:29 -0800, Chad Austin a écrit :
> If socket.error, xmlrpclib.Fault, httplib.HTTPException, etc. all extended
> StandardError, then we would probably be fine with that approach. But I
> think
> the majority of exceptions, both in the standard library and our co
Guido van Rossum python.org> writes:
>
> I ran into the need of monkeypatching a large number of classes (for
> what I think are very good reasons and invented two new recipes.
> These don't depend on Py3k, and the second one actually works all the
> way back to Python 2.2. Neither of these allo
Christian Heimes cheimes.de> writes:
>
> I assume ~/.local was first introduced by the freedesktop.org people. On
> my box it's only used for some desktop related apps like
> ~/.local/share/Trash or XFC4.
Same here, only ~/.local/share is used (on two boxes, one Mandriva and one
Ubuntu).
Raymond Hettinger rcn.com> writes:
> Go ask a dozen people if they are surprised that int(3.7) returns 3.
> No one will be surprised (even folks who just use Excel or VB). It
> is foolhardy to be a purist and rage against the existing art:
>
Well, for what it's worth, here are MySQL's own two ce
Hello,
> Two points. Firstly, regarding MySQL as authoritative from a standards
> point of view is bound to lead to trouble, since they have always played
> fast and loose with the standard for reasons (I suspect) of
> implementation convenience.
To that I heartily agree. I was just pointing
Ralf Schmitt gmail.com> writes:
>
> I have also setup a mirror using mercurial: http://hgpy.de/py/It contains the
2.4, 2.5, trunk and py3k branches (in case anyone wants to compare this to bzr).
I see your trunk history is stripped. For those who want the complete trunk
history (back to 17 years
Hi,
Paul Moore gmail.com> writes:
>
> Excellent! For what it's worth, hg clone took 5 minutes on my PC (with
> broadband access). That's faster than simply downloading the Bazaar
> shared repository tarball (which took 13 minutes)!
>
> Are you keeping the mirror updated with respect to Subvers
Hi,
I'm attempting some bytecode tweaks (see http://bugs.python.org/issue2459) and
I've got two questions about jump instructions:
- Why are there both relative and absolute jump instructions? The traditional
rationale for relative jumps (apart from position-independent code) is to allow
for shor
Wow, thanks to both of you (Phillip & Skip) for the fast answers.
Just in case anyone has time to spare, I have more pesky questions (and a
working patch :-)) in the aforementioned bug entry
(http://bugs.python.org/issue2459).
Regards
Antoine.
___
Py
Hello,
It seems this subject has had quite a bit of history. Tim Peters demonstrated
the problem in 2003 in this message:
http://mail.python.org/pipermail/python-dev/2003-June/036537.html
In short, Python file objects release the GIL before calling any C stdlib
function on their embedded FILE po
Guido van Rossum python.org> writes:
> Your solution (a counter) seems fine except I think perhaps the
> close() call should not raise IOError -- instead, it should set a flag
> so that the thread that makes the counter go to zero can close the
> thread (after all the file got closed while it was
Greg Ewing canterbury.ac.nz> writes:
>
> Really? Nobody else wants a convenient way to
> distinguish program bugs from exceptions caused
> by external factors?
Why do you want to derive program bugs from EnvironmentError ? Usually I derive
them from ValueError, RuntimeError or simply Exception.
Brett Cannon python.org> writes:
> As http://bugs.python.org/issue2705 points out, though, since the
> function has been documented as being allowed to be overridden, this
> potentially breaks existing showwarning() implementations. That means
> something needs to change.
>
> One option is to int
Steven D'Aprano pearwood.info> writes:
>
> I think you're exaggerating a tad here. Why would you be "very confused"
> when you see TITLEPATTERN() or foo(callback=TITLEPATTERN)? What else
> would TITLEPATTERN be but a callable when it's being used as a
> callable?
The real problem is this exam
pobox.com> writes:
>
> Back in r29829, Guido commented out the security hole warning for
> tempfile.mktemp:
>
[...]
>
> Comment out the warnings about mktemp(). These are too annoying, and
> often unavoidable.
>
> Any thought about whether this warning should be restored? We're 5+ ye
Martin v. Löwis v.loewis.de> writes:
>
> Are you (or are you not) aware that this strategy allows for malicious
> code to provide you with a fake JPEG file? If so, does it not concern
> you?
Yes, I'm aware of it and no, it doesn't concern me. When you write a processing
script for internal use t
Hello,
For those of you who have been using my Mercurial mirrors of the Python SVN
repository, I had to move them to another site as the original site has been
down for a few days for unknown reasons. Here are the new URLs:
http://hg.pitrou.net/public/cpython/trunk/
http://hg.pitrou.net/public/p
(just my 2 eurocents)
Guido van Rossum python.org> writes:
>
> I'm not against this, but so far I've not been able to come up with a
> good set of methods to endow the String ABC with.
If we stay minimalistic we could consider that the three basic operations that
define a string are:
- testing
Georg Brandl gmx.net> writes:
> I'd argue that "find" is more primitive than "split" -- split is intuitively
> implemented using find and slicing, but implementing find using split and
> len is unintuitive. (Of course, "index" can be used instead of "find".)
I meant semantically primitive. I thi
Georg Brandl gmx.net> writes:
>
> It does, but I don't see how it contradicts my proposition. find() takes a
> substring as well.
Well, I'm not sure what your proposal was :-)
Did you mean to keep split() out of the String interface, or to provide a
default implementation of it based on find() a
Georg Brandl gmx.net> writes:
> You wrote:
>
> > If we stay minimalistic we could consider that the three basic
operations that
> > define a string are:
> > - testing for substring containment
> > - splitting on a substring into a list of substrings
> > - slicing in order to extract a substr
Stefan Behnel behnel.de> writes:
> BTW, I noticed that the code in typeobject.c uses "DECREF before set" two
> times, like this:
>
> method_cache[h].version = type->tp_version_tag;
> method_cache[h].value = res; /* borrowed */
> Py_INCREF(name);
>
Simon Cross gmail.com> writes:
> My tests show that the old-style % formatting is much faster when the
> final string is 20 characters or less:
>
> $ ./python -m timeit "'|||...%s' % '12'"
> 1000 loops, best of 3: 0.0764 usec per loop
You are the victim of a constant-folding opt
Raymond Hettinger rcn.com> writes:
> Also, starting with Py3.0, strings are
> essentially abstract sequences of code points, meaning that an encode() method
> is essential to being able to usefully transform them back into concrete data.
Well, that depends:
- is a String the specification of a ge
Raymond Hettinger rcn.com> writes:
>
> By subclassing Sequence, we get index() and count() mixins for free.
>
It seems to me that Sequence.index()/count() and String.index()/count()
shouldn't have the same semantics.
In the former case they search for items in the Sequence, in the latter case
Guido van Rossum python.org> writes:
> I'd prefer the 2.6 code base to
> stay true to 2.x, and the 3.0 code base start afresh where it makes
> sense. We should reindent more of the 3.0 code base to use
> 4-space-indents in C code too.
Is there any reason reindenting shouldn't be done for 2.6 too?
Benjamin Peterson gmail.com> writes:
> On Tue, Jun 3, 2008 at 5:02 PM, Jesse Noller gmail.com> wrote:
> > What about also including a patch to fix the threading api to be pep 8
> > compliant?
>
> I doubt that will be accepted because of the closeness threading has
> to Java's APIs.
Is this real
Michael Foord voidspace.org.uk> writes:
> Simple string formatting with %s and a single object or a tuple meets
> >90% of my string formatting needs.
Not to mention that e.g. "%r" % s is much simpler than "{0!r}".format(s)
(if I got the format spec right).
cheers
Antoine.
__
Nick Coghlan gmail.com> writes:
>
> %r is about the worst case for the new syntax relative to the old - two
> characters become 5.
Well there are other very common "worst cases" - namely %d, %f (and probably
a few less commonly used ones such as %X).
> For dictionary formatting, str.format() i
Calvin Spealman socialserve.com> writes:
> Traceback (most recent call last):
>File "", line 1, in
>File "", line 3, in A
>File "", line 5, in d
>File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
> python2.5/functools.py", line 33, in update_wrapper
> setattr(wrap
Calvin Spealman socialserve.com> writes:
>
> staticmethod doesn't wrap anything, it just creates a descriptor on
> the class with a __get__ that returns the original, untouched
> callable. Doesn't even care _what_ the thing you use it on is
> (function, other callable, or something else ent
Benjamin Peterson gmail.com> writes:
>
> On Thu, Jun 12, 2008 at 10:41 PM, Guido van Rossum python.org>
wrote:
> >
> > Let's all remember this and make sure not to drop "code bombs" on each
> > other.
>
> Ok! I'd like everybody to know that I'm working on Python tests on a
> Bazaar branch. [
dbpokorny gmail.com gmail.com> writes:
>
> If you don't like the fact that your web application framework loses
> the order of its key:value pairs relative to the page, then you should
> bring it up with the developers.
Who will then point up that to retain that order while providing you
with a
Phillip J. Eby telecommunity.com> writes:
>
> As for the other uses for ordered dictionaries, I find it simplest to
> just use a list of key,value pairs, and only transform it to a
> dictionary or dictionary-like structure as needed, using tools like
> the cgi module, the email package, or wsg
Amaury Forgeot d'Arc gmail.com> writes:
> if family == 'AF_INET':
> -return ('localhost', 0)
> +return ('', 0)
> elif family == 'AF_UNIX':
> return tempfile.mktemp(prefix='listener-', dir=get_temp_dir())
> elif family == 'AF_PIPE':
Doesn't it have important
Amaury Forgeot d'Arc gmail.com> writes:
>
> OK, I am not a tcp expert.
> How about the following patch?
> It seems to me that it is wrong for the server to lie about the
> address it listens to.
Maybe I'm missing something but... if the client part defaults to connecting
to "localhost" in TCP mo
Hi,
> Maciej Fijalkowski did an opcode analysis for PyPy,
> it also shows the relative frequency of opcodes following a
> specifc one:
>
> http://codespeak.net/svn/user/fijal/opcodes.txt
Nice, but we have to be careful here: what is the tested workload?
For example, I find it hard to believe th
Jesse Noller gmail.com> writes:
>
> The server component *is* listening to localhost by default. The
> client in the code I pasted has the server's .address attribute passed
> into it to tell the client where to connect to.
So I take it that the .address attribute is different from "localhost",
Georg Brandl gmx.net> writes:
> Agreed; is there a way for a JUMP to end up without popping the top
> after jumping? It would have to do a DUP first then.
For example:
>>> def f(x, y):
... return x and y
...
>>> import dis
>>> dis.dis(f)
2 0 LOAD_FAST0 (x)
Hi,
Kevin Jacobs bioinformed.com> gmail.com> writes:
>
> +1 on a C API for enabling and disabling GC. I have several instances where
I create a large number of objects non-cyclic objects where I see huge GC
overhead (30+ seconds with gc enabled, 0.15 seconds when disabled).
Could you try t
Le vendredi 20 juin 2008 à 17:44 +0200, Amaury Forgeot d'Arc a écrit :
> In short: the gc is tuned for typical usage. If your usage of python
> is specific,
> use gc.set_threshold and increase its values.
It's fine for people "in the know" who take the time to test their code
using various gc para
Le samedi 21 juin 2008 à 10:33 +0200, "Martin v. Löwis" a écrit :
> > I don't think expecting people to tweak gc parameters when they witness
> > performance problems is reasonable.
>
> What follows from that? To me, the natural conclusion is "people who
> witness performance problems just need to
3701 - 3800 of 4909 matches
Mail list logo
