Le lundi 12 juillet 2010 à 23:04 +0100, Michael Foord a écrit :
> Given how high traffic python-checkins is I don't consider that a
> reasonable place to send follow-up and nor do I consider it the
> responsibility of committers to monitor it.
You don't have to receive e-mail from it. Just take
Antoine Pitrou writes:
> You don't have to receive e-mail from it. Just take a look at the
> archives from time to time after you have done some commits.
> In a threaded view, it's easy to spot the few messages which aren't
> commit notifications, since they are the only one not at the
> top-
On Tue, Jul 13, 2010 at 11:05 AM, Stephen J. Turnbull
wrote:
> Antoine Pitrou writes:
>
> > You don't have to receive e-mail from it. Just take a look at the
> > archives from time to time after you have done some commits.
> > In a threaded view, it's easy to spot the few messages which aren't
> I was actually going to suggest something along those lines post
> transition, since Hg will have an email address for everyone - leave
> push notifications coming from the bot (so existing filters based on
> the bot address keep working), but include the push author in the
> reply-to field.
IIR
On Jul 13, 2010, at 09:56 PM, Éric Araujo wrote:
>Note that nothing in Mercurial forces you to have a parsable
>“Name ” user name, it’s just a good practice. Dirkjan’s mapping
>uses a dummy to...@python.org address for unknown IDs, which probably
>means the other tools he’s writing depend on an em
This is getting a little off-topic, but let me just respond to this...
On Tue, Jul 13, 2010 at 22:10, Barry Warsaw wrote:
> Does Mercurial have a similar feature? If so, I would suggest that we enable
> that and require committers to use registered gpg keys to sign their commits.
> We'd always h
Dirkjan Ochtman writes:
> - http://bitbucket.org/mg/commitsigs is another extension, which takes
> a different tack to signing (I believe it doesn't sign the commit
> metadata, only the file tree, which lets it sign before the commit is
> finished, meaning it doesn't take up an extra cset).
It d
I just freed up a bunch, but not all, of the messages to python-checkins being
held for moderator approval. We could use some additional moderator
volunteers. I'm not sure Fred is still moderating the list, and I suck at it.
Please email me directly if you'd like to help out, have experience mod
Raymond requested, and Guido concurred, that the python-checkins mailing
list Reply-To header munging be turned off. I've now done this.
Previously, follow-ups to checkins would be addressed to python-dev.
Now, follow-ups will stay on the python-checkins list and will not
appear here, unless the
Terry Reedy wrote:
>> Just end user experience's two cents here
>> (btw, this line is correct at English level?)
>
> Since you asked...your question would be better written "is this line
> correct English?"
> And the line before, while not formal English of the kind needed, say, for
> Decimal d
On Sat, 27 May 2006, "Martin v. Löwis" wrote:
[...]
Just end user experience's two cents here
(btw, this line is correct at English level?)
[...]
Wouldn't it be still be conventional to have an article somewhere?
e.g. " Just /some/ end user's two cents here"
Yes, but "one" (or maybe "an") ra
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Terry Reedy wrote:
>>> Just end user experience's two cents here
>>> (btw, this line is correct at English level?)
>>
>> Since you asked...your question would be better written "is this line
>> correct English?"
>>
Martin v. Löwis wrote:
>
>>>Just end user experience's two cents here
>>>(btw, this line is correct at English level?)
>
> Wouldn't it be still be conventional to have an article somewhere?
> e.g. " Just /some/ end user's two cents here"
Or "Just two cents' worth of end-user experience here",
wh
I haven't gotten emails for any of the commits I've done in the last
12 hours or so.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/o
On 12/07/2010 23:48, Eric Smith wrote:
On 7/12/2010 6:04 PM, Michael Foord wrote:
Given how high traffic python-checkins is I don't consider that a
reasonable place to send follow-up and nor do I consider it the
responsibility of committers to monitor it. As you said earlier this
*isn't* in our
On Mon, Jul 12, 2010 at 16:42, Michael Foord wrote:
> On 12/07/2010 23:48, Eric Smith wrote:
>
>> On 7/12/2010 6:04 PM, Michael Foord wrote:
>>
>>> Given how high traffic python-checkins is I don't consider that a
>>> reasonable place to send follow-up and nor do I consider it the
>>> responsibili
Am 13.07.2010 22:29, schrieb Brett Cannon:
> Given how high traffic python-checkins is I don't consider that a
> reasonable place to send follow-up and nor do I consider it the
> responsibility of committers to monitor it. As you said earlier
> this
>
On 7/14/2010 4:21 AM, Georg Brandl wrote:
Am 13.07.2010 22:29, schrieb Brett Cannon:
Given how high traffic python-checkins is I don't consider that a
reasonable place to send follow-up and nor do I consider it the
responsibility of committers to monitor i
On Wed, Jul 14, 2010 at 01:36, Eric Smith wrote:
> On 7/14/2010 4:21 AM, Georg Brandl wrote:
>
>> Am 13.07.2010 22:29, schrieb Brett Cannon:
>>
>> Given how high traffic python-checkins is I don't consider
>>> that a
>>> reasonable place to send follow-up and nor do I con
On Thu, Jul 15, 2010 at 5:22 AM, Brett Cannon wrote:
> Actually, I probably wouldn't. =) When it gets to explicit code, a design
> decision has been made, so I do not need to worry about involving the
> general public in some low-level technical discussion that won't impact
> them.
Yep, that's my
On Tue, Jul 13, 2010 at 2:42 AM, Michael Foord
wrote:
>>>
>>> Given how high traffic python-checkins is I don't consider that a
>>> reasonable place to send follow-up and nor do I consider it the
>>> responsibility of committers to monitor it. As you said earlier this
>>> *isn't* in our standard d
Hello,
I consult very regularly (100x a day) the python-checkins and
python-300-checkins mailing list archives:
http://mail.python.org/pipermail/python-checkins/2008-October/date.html#end
http://mail.python.org/pipermail/python-3000-checkins/2008-October/date.html#end
But they did not receive the
On 7/29/2012 4:42 PM, Barry Warsaw wrote:
I just freed up a bunch, but not all, of the messages to python-checkins being
held for moderator approval. We could use some additional moderator
volunteers. I'm not sure Fred is still moderating the list, and I suck at it.
It seems that me that mess
[Anna Ravenscroft]
I think this is a really good point. next() is supposed to get used, by
coders, in regular code - so it shouldn't be __next__. I can understand the
desire for both forms, although that seems it would clutter things up
unnecessarily - particularly if the two do
On Mar 6, 2006, at 10:17 AM, Tim Peters wrote:
...
> How's everyone doing, BTW?
Swimmingly, thanks! Too busy to breathe, or come to pycon:-(, but,
happy as a lark.
> I think I picked up the Texas Mystery
> Disease from Holger Krekel -- bed-ridden 20 hours Saturday, and most
> of Sunday, w
On Mon, May 25, 2009, Benjamin Peterson wrote:
>
> I haven't gotten emails for any of the commits I've done in the last
> 12 hours or so.
Forwarded to postmas...@python.org -- if there's a problem with the
checkins process itself, that won't help. Have you verified that the
commits are landing?
Aahz pythoncraft.com> writes:
>
> Forwarded to postmaster python.org -- if there's a problem with the
> checkins process itself, that won't help. Have you verified that the
> commits are landing? (I.e. is svn working properly?)
Yes, it is.
> Also, if you
> could double-check the python-chec
Hello Larry,
> You're right, my changes aren't backwards compatible. I thought it was
> reasonable for four reasons:
>
> 1. The CObject API isn't safe. It's easy to crash Python 2.6 in just a
> few lines by mixing and matching CObjects. Switching Python to capsules
> prevents a class of ex
Just a reply to one part of your message, as I really need to get back
to work for now.
Antoine Pitrou wrote:
I think solution #1 would be the best one.
#2 looks too complicated.
#2 is a seven-line diff, below.
/larry/
Index: cobject.c
=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 11, 2007, at 9:15 AM, Kristján Valur Jónsson wrote:
> The SVN repository hasn‘t answered http requests since this
> morning. Anyone know what is up with that?
Known breakage. We're working on it.
- -Barry
-BEGIN PGP SIGNATURE-
Vers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 11, 2007, at 10:34 AM, Barry Warsaw wrote:
> On Apr 11, 2007, at 9:15 AM, Kristján Valur Jónsson wrote:
>> The SVN repository hasn‘t answered http requests since this
>> morning. Anyone know what is up with that?
> Known breakage. We're wor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 25, 2009, at 11:49 AM, Antoine Pitrou wrote:
Barry Warsaw python.org> writes:
Besides, certain developments like support for the svn wire protocol
in bzr would make the WFC (we fear change :) argument moot.
This is an argument *against*
Barry Warsaw python.org> writes:
> >>
> >> Besides, certain developments like support for the svn wire protocol
> >> in bzr would make the WFC (we fear change :) argument moot.
> >
> > This is an argument *against* the usefulness of switching!
>
> Why?
>
> This simply allows those who are happy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 25, 2009, at 12:44 PM, Antoine Pitrou wrote:
Barry Warsaw python.org> writes:
Besides, certain developments like support for the svn wire
protocol
in bzr would make the WFC (we fear change :) argument moot.
This is an argument *agains
On 2 February 2016 at 05:21, raymond.hettinger
wrote:
> https://hg.python.org/cpython/rev/0731f097157b
> changeset: 100142:0731f097157b
> parent: 100140:c7f1acdd8be1
> user:Raymond Hettinger
> date:Mon Feb 01 21:21:19 2016 -0800
> summary:
> merge
>
> files:
> Doc/libra
It seems that python-checkins isn't receiving any new commits since
the 8th of September. A quick check of the github page shows activity
since then, as do the buildbots.
Just a heads up.
--
Jeremy Kloth
___
Python-Dev mailing list -- python-dev@pytho
On Tue, Feb 10, 2015, at 23:37, raymond.hettinger wrote:
> https://hg.python.org/cpython/rev/7d826a6b92a1
> changeset: 94582:7d826a6b92a1
> user:Raymond Hettinger
> date:Tue Feb 10 22:37:22 2015 -0600
> summary:
> Update copyright.
>
> files:
> Modules/_collectionsmodule.c
> After migration
> ===
>
> +* set up automatic installation of changes to ssh keys, decide upon
> + account managers
I would like account managers to be decided before the conversion.
I personally won't be available as an account manager anymore. The new
account managers are then
Notice the subject line. Can we make commit messages contain the named branch
that the change applies to? The 'cpython' in the header doesn't really tell
me whether I should care about this diff or not.
Say the change applied to 2.6 but I only care about Python 3. It would be
nice if I could ju
Am 26.02.2011 19:12, schrieb Barry Warsaw:
> Notice the subject line. Can we make commit messages contain the named branch
> that the change applies to?
If you don't want this request to be forgotten, add it to todo.txt in
the pymigr repo.
Regards,
Martin
___
On 27 February 2011 05:12, Barry Warsaw wrote:
> I guess it's possible for change notifications to encompass multiple named
> branches though, right? I'm not sure what to do about that, but it seems
> like
> a less common use case.
>
Are the change notifications per-commit? If so, there's no wa
Le jeudi 09 juin 2011 à 02:30 +0200, brian.curtin a écrit :
> http://hg.python.org/cpython/rev/f1509fc75435
> changeset: 70715:f1509fc75435
> branch: 2.7
> parent: 70661:6e7a98cfcfab
> user:Brian Curtin
> date:Wed Jun 08 19:29:53 2011 -0500
> summary:
> Merge
FYI thi
Le 04/10/2011 01:35, benjamin.peterson a écrit :
http://hg.python.org/cpython/rev/64495ad8aa54
changeset: 72634:64495ad8aa54
user:Benjamin Peterson
date:Mon Oct 03 19:35:07 2011 -0400
summary
fix formatting
+++ b/Objects/unicodeobject.c
@@ -1362,8 +1362,8 @@
re
2011/10/4 Victor Stinner :
> Le 04/10/2011 01:35, benjamin.peterson a écrit :
>>
>> http://hg.python.org/cpython/rev/64495ad8aa54
>> changeset: 72634:64495ad8aa54
>> user: Benjamin Peterson
>> date: Mon Oct 03 19:35:07 2011 -0400
>> summary
>> fix formatting
>>
>> +++ b/Objects/un
On Thu, Feb 9, 2012 at 7:52 AM, victor.stinner
wrote:
> http://hg.python.org/cpython/rev/f8409b3d6449
> changeset: 74832:f8409b3d6449
> user: Victor Stinner
> date: Wed Feb 08 14:31:50 2012 +0100
> summary:
> PEP 410
Ah, even when written by a core dev, a PEP should still be at
On Thu, Feb 9, 2012 at 2:48 PM, Nick Coghlan wrote:
> On Thu, Feb 9, 2012 at 7:52 AM, victor.stinner
> wrote:
>> http://hg.python.org/cpython/rev/f8409b3d6449
>> changeset: 74832:f8409b3d6449
>> user: Victor Stinner
>> date: Wed Feb 08 14:31:50 2012 +0100
>> summary:
>> PEP 410
>>> changeset: 74832:f8409b3d6449
>>> user: Victor Stinner
>>> date: Wed Feb 08 14:31:50 2012 +0100
>>> summary:
>>> PEP 410
>>
>> Ah, even when written by a core dev, a PEP should still be at Accepted
>> before we check anything in. PEP 410 is still at Draft.
>
> Never mind, I ju
On Thu, Feb 9, 2012 at 7:32 PM, Victor Stinner
wrote:
changeset: 74832:f8409b3d6449
user: Victor Stinner
date: Wed Feb 08 14:31:50 2012 +0100
summary:
PEP 410
>>>
>>> Ah, even when written by a core dev, a PEP should still be at Accepted
>>> before we che
On Thu, Dec 4, 2008 at 2:36 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I would like to merge mailing lists, now that the design and first
> implementation of Python 3000 is complete. In particular, I would
+1
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which reality is w
On Thu, May 24, 2012 at 8:10 PM, eric.smith wrote:
> + Lib/test/namspace_pkgs
Typo: s/namspace/namespace/
> +Here we add the parent directories to ``sys.path``, and show that the
> +portions are correctly found::
> +
> + >>> import sys
> + >>> sys.path += ['Lib/test/namespace_pkgs/parent
On May 24, 2012 11:29 PM, "Eric V. Smith" wrote:
>
> Possibly I am being too tricky here by modifying parent.__path__, and I
> should just modify sys.path again, as you suggest. But I was trying to
> show that modifying parent.__path__ will also work.
Modifying namespace package __path__ attribut
On Fri, Apr 28, 2006 at 01:13:21AM +0200, thomas.wouters wrote:
> - Warn-raise ImportWarning when importing would have picked up a directory
>as package, if only it'd had an __init__.py. This swaps two tests (for
>case-ness and __init__-ness), but case-test is not really more expensive,
>
A.M. Kuchling wrote:
> On Fri, Apr 28, 2006 at 01:13:21AM +0200, thomas.wouters wrote:
>> - Warn-raise ImportWarning when importing would have picked up a directory
>>as package, if only it'd had an __init__.py. This swaps two tests (for
>>case-ness and __init__-ness), but case-test is not
A.M. Kuchling wrote:
> On Fri, Apr 28, 2006 at 01:13:21AM +0200, thomas.wouters wrote:
>> - Warn-raise ImportWarning when importing would have picked up a directory
>>as package, if only it'd had an __init__.py. This swaps two tests (for
>>case-ness and __init__-ness), but case-test is not
On 4/29/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
So the relatively non-controversial bit (improving the error reporting) wasadded immediately, and the controversial bit postponed to see if the bettererror reporting had any effect on the demand for it.
This is exactly how I intended it, and I bel
Actually after all the -1 responses I wasn't going to reconsider this
for 2.x; maybe for py3k. Most of the -1 votes were unconditional; only
a few respondents thought that I was proposing it for 2.5.
--Guido
On 4/29/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>
>
> On 4/29/06, Nick Coghlan <[EM
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Actually after all the -1 responses I wasn't going to reconsider this
> for 2.x; maybe for py3k.
I think there may be proposals to review and possibly revise the packing
and import mechanisms for 3.0. So I think y
I may be misunderstanding what you wrote. I thought that packing and
join were *only* being discussed in a py3k context? If they are being
discussed in a 2.x context, then yes, these discussions ought to be
moved to py3k.
--Guido
On 4/29/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Guido van R
Fredrik Lundh wrote:
Yes. It went to my todo list and is awaiting some free raymond-cycles
to finish it up. I've been task saturated of late but would like to get
this a number of other patches complete for Py2.5.
no need to wait for any raymond-cycles here; just point me
On 5/25/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Raymond Hettinger wrote:
>
> > IIRC, Skip had developed a smart version that returned lazy string
> > objects that kept a reference and pointers to the original string
> > (instead of making its own copy of the string components). The string
>> skip? was this a real design or a Py3K bluesky idea?
Just about nothing I do is a real design. I don't remember the
weather conditions that day either. I was probably just noodling around
based upon discussions on python-dev that were mutated in my brain by gamma
rays from Alpha Centau
On Thursday 21 September 2006 08:35, Armin Rigo wrote:
> Thanks for the hassle! I've got another bit of it for you, though. The
> freezed 2.5 documentation doesn't seem to be available on-line. At
> least, the doc links from the release page point to the 'dev' 2.6a0
> version, and the URL fo
>+@unittest.skipIf(sys.platform.startswith('win'),
>+"This test is only appropriate for POSIX-like
systems.")
Is win32 the only non-POSIX supported platform now that OS 9 support is
gone? I find those values in the docs for sys.platform: win32, cygwin,
darwin, os2, os2
> +if branch in ('trunk', 'legacy-trunk',
> + '2.0', '2.1', '2.2', '2.3', '2.4', '3.0'):
Wouldn’t using a whitelist instead of a blacklist protect against new
named branches too?
___
Python-Dev mailing list
Python-Dev@python.
On Sat, 26 Feb 2011 22:36:47 +0100
Éric Araujo wrote:
> > +if branch in ('trunk', 'legacy-trunk',
> > + '2.0', '2.1', '2.2', '2.3', '2.4', '3.0'):
>
> Wouldn’t using a whitelist instead of a blacklist protect against new
> named branches too?
Then we will have to fix
> Then we will have to fix the hook each time we want to add a new
> legitimate branch.
The alternative is to edit the hook each time we want to remove a former
legitimate branch, plus have another hook to refuse new named branches.
> I have no preference really.
Looks like a ±0 to me :)
Regards
Am 27.02.2011 00:21, schrieb Éric Araujo:
>> Then we will have to fix the hook each time we want to add a new
>> legitimate branch.
> The alternative is to edit the hook each time we want to remove a former
> legitimate branch, plus have another hook to refuse new named branches.
The question is w
On Sun, Feb 27, 2011 at 5:26 PM, "Martin v. Löwis" wrote:
> There is nothing that prevents people from tagging the tree currently
> in subversion, but most of the time, only the release manager does any
> tagging.
>
> If you think that it's a likely problem that people create named
> branches by m
On Sat, Feb 26, 2011 at 11:48 PM, Nick Coghlan wrote:
> On Sun, Feb 27, 2011 at 5:26 PM, "Martin v. Löwis"
> wrote:
> > If you think that it's a likely problem that people create named
> > branches by mistake, then we should have a hook.
>
> I suspect the concern is that people may create named
On Mon, Mar 7, 2011 at 20:57, benjamin.peterson
wrote:
> http://hg.python.org/cpython/rev/a7e0cff05597
> changeset: 68323:a7e0cff05597
> branch: 3.1
> parent: 68317:d9125bf3bac5
> user:Benjamin Peterson
> date:Mon Mar 07 22:50:37 2011 -0600
> summary:
> transform izip
On Mon, May 30, 2011 at 8:25 PM, tarek.ziade wrote:
> + old_out = sys.stdout
> + sys.stderr = StringIO()
> + try:
> + dist = self.run_setup('install_dist', '--prefix=' +
> self.root_dir)
> + finally:
> + sys.sterr = old_out
There's actually a hel
2011/6/11 Terry Reedy :
>
>> +What's New in Python 3.1.5?
>> +===
>> +
>> +*Release date: -XX-XX*
>> +
>> +Core and Builtins
>> +-
>> +
>> +Library
>> +---
>> +
>> +
>
> I presume that only security patches should be added.
Indeed.
--
Regards,
Ben
On Fri, Jun 17, 2011 at 7:33 AM, raymond.hettinger
wrote:
> http://hg.python.org/cpython/rev/0fe3b81c7c89
> changeset: 70822:0fe3b81c7c89
> branch: 3.2
> parent: 70819:8a9d25804c3d
> user: Raymond Hettinger
> date: Thu Jun 16 22:32:10 2011 +0100
> summary:
> Fix typo.
>
Le samedi 18 juin 2011 à 02:51 +0200, benjamin.peterson a écrit :
> .. function:: dump_traceback(file=sys.stderr, all_threads=True)
>
> - Dump the traceback of all threads, or of the current thread if
> *all_threads*
> - is ``False``, into *file*.
> + Dump the traceback of all threads int
On Sun, Aug 14, 2011 at 9:53 AM, antoine.pitrou
wrote:
> http://hg.python.org/cpython/rev/0273d0734593
> changeset: 71862:0273d0734593
> user: Antoine Pitrou
> date: Sun Aug 14 01:51:52 2011 +0200
> summary:
> Monotonic, not monotonous
>
> files:
> Lib/test/pickletester.py | 2
On Tue, Aug 16, 2011 at 11:30 AM, antoine.pitrou
wrote:
> +Serializing "pseudo-global" objects
> +---
> +
> +Objects which are not module-global, but should be treated in a similar
> +fashion -- such as methods [4]_ or nested classes -- cannot currently be
> +pickle
On Tue, 16 Aug 2011 12:35:48 +1000
Nick Coghlan wrote:
> On Tue, Aug 16, 2011 at 11:30 AM, antoine.pitrou
> wrote:
> > +Serializing "pseudo-global" objects
> > +---
> > +
> > +Objects which are not module-global, but should be treated in a similar
> > +fashion -- s
On Tue, Aug 16, 2011 at 7:25 PM, Antoine Pitrou wrote:
> On Tue, 16 Aug 2011 12:35:48 +1000
> Nick Coghlan wrote:
>> On Tue, Aug 16, 2011 at 11:30 AM, antoine.pitrou
>> wrote:
>> > +Serializing "pseudo-global" objects
>> > +---
>> > +
>> > +Objects which are not m
On Tue, Aug 16, 2011 at 9:23 PM, Antoine Pitrou wrote:
> On Tue, 16 Aug 2011 20:15:51 +1000
> Nick Coghlan wrote:
>> >
>> > Oops, I admit I hadn't read PEP 395.
>> > PEP 395 focuses on module aliasing, while the suggestion above focuses
>> > on the path of objects in modules. How can we reconcile
Is there some reason str.format had such major surgery done to it? It
appears parts of it were removed from stringlib. I had not even thought
to look at the code before it was merged, as it never occurred to me
anyone would do that.
I left it in stringlib even in 3.x because there's the occasional
Am 29.09.2011 01:21, schrieb Eric V. Smith:
> Is there some reason str.format had such major surgery done to it?
Yes: I couldn't figure out how to do it any other way. The formatting
code had a few basic assumptions which now break (unless you keep using
the legacy API). Primarily, the assumption
On 10/1/2011 9:26 AM, "Martin v. Löwis" wrote:
> Am 29.09.2011 01:21, schrieb Eric V. Smith:
>> Is there some reason str.format had such major surgery done to it?
>
> Yes: I couldn't figure out how to do it any other way. The formatting
> code had a few basic assumptions which now break (unless yo
On Sat, Oct 1, 2011 at 4:07 PM, Eric V. Smith wrote:
> On the other hand, not having this code in stringlib would certainly be
> liberating! Maybe I'll take this opportunity to clean it up and simplify
> it now that it's free of the stringlib constraints.
Yeah, don't sacrifice speed in str.format
Le 04/10/2011 01:34, benjamin.peterson a écrit :
http://hg.python.org/cpython/rev/afb60b190f1c
changeset: 72633:afb60b190f1c
user:Benjamin Peterson
date:Mon Oct 03 19:34:12 2011 -0400
summary:
fix compiler warnings
+++ b/Objects/unicodeobject.c
@@ -369,6 +369,12 @@
}
2011/10/4 Victor Stinner :
> Le 04/10/2011 01:34, benjamin.peterson a écrit :
>>
>> http://hg.python.org/cpython/rev/afb60b190f1c
>> changeset: 72633:afb60b190f1c
>> user: Benjamin Peterson
>> date: Mon Oct 03 19:34:12 2011 -0400
>> summary:
>> fix compiler warnings
>>
>> +++ b/Ob
Why does the function even return a value? As Benjamin said, it is just a
bunch of asserts with return 1 at the end.
I believe another way you can get rid of "statement with no effect" is to
cast return value to void, like (void)_PyUnicode_CHECK(unicode).
Thank you,
Vlad
On Tue, Oct 4, 2011 at 4
Le 05/10/2011 00:30, Vlad Riscutia a écrit :
Why does the function even return a value? As Benjamin said, it is just
a bunch of asserts with return 1 at the end.
It's just to be able to write assert(_PyUnicode_CheckConsistency(...)).
assert() is just used to remove the instruction in release m
Isn't now final?
2011/10/12 antoine.pitrou :
> http://hg.python.org/peps/rev/f50f0e14c774
> changeset: 3962:f50f0e14c774
> parent: 3959:2e1f0462a847
> user: Antoine Pitrou
> date: Thu Oct 13 02:01:21 2011 +0200
> summary:
> Mark PEP accepted.
>
> files:
> pep-3151.txt | 10
On Sat, Oct 04, 2008 at 12:14:43AM +0200, Amaury Forgeot d'Arc wrote:
> Do other subscribed people receive these commit messages?
> Is there a problem with the mailer, or some SVN trigger?
It looks like mail from dinsdale.python.org to mail.python.org isn't
working due to a DNS issue:
rcpt to: [E
> I know there's a transition to new IP addresses going on for the
> python.org machines, but Thomas or Sean probably needs to do something
> with the DNS for this.
IIUC, it would be sufficient if these addresses get recognized as local.
Meanwhile, I have disabled the new interfaces.
Regards,
Mar
On 4/2/2013 5:15 PM, Eric V. Smith wrote:
> On 10/3/2012 8:59 PM, jesus.cea wrote:
>>
>> -Solaris and derived platforms have a new class :class:`select.devpoll`
>> -for high performance asyncronous sockets via :file:`/dev/poll`.
>> +Solaris and derivatives platforms have a new class :class:`selec
On 10/3/2012 8:59 PM, jesus.cea wrote:
>
> -Solaris and derived platforms have a new class :class:`select.devpoll`
> -for high performance asyncronous sockets via :file:`/dev/poll`.
> +Solaris and derivatives platforms have a new class :class:`select.devpoll`
> +for high performance asynchronous
On Wed, 26 Jun 2013 17:39:07 +0200, lukasz.langa
wrote:
> -Deferred; see
> +Rejected; see
> +http://mail.python.org/pipermail/python-ideas/2013-June/021610.html
> +
> +This PEP has been deferred since 2006; see
> http://mail.python.org/pipermail/python-dev/2006-February/06071
On 26 cze 2013, at 18:18, R. David Murray wrote:
> On Wed, 26 Jun 2013 17:39:07 +0200, lukasz.langa
> wrote:
>> -Deferred; see
>> +Rejected; see
>> +http://mail.python.org/pipermail/python-ideas/2013-June/021610.html
>> +
>> +This PEP has been deferred since 2006; see
>> htt
On 27 Jun 2013 03:12, "Łukasz Langa" wrote:
>
> On 26 cze 2013, at 18:18, R. David Murray wrote:
>
>> On Wed, 26 Jun 2013 17:39:07 +0200, lukasz.langa <
python-check...@python.org> wrote:
>>>
>>> -Deferred; see
>>> +Rejected; see
>>> +http://mail.python.org/pipermail/python-ideas/2013
On 27 cze 2013, at 00:51, Nick Coghlan wrote:
> On 27 Jun 2013 03:12, "Łukasz Langa" wrote:
> > This was a mention of an alternative possible syntax. I don't feel it was
> > worth keeping this particular one while not discussing any other
> > alternatives at all. If you'd rather keep this infor
2012/3/27 guido.van.rossum :
> http://hg.python.org/peps/rev/b9f43fe69691
> changeset: 4152:b9f43fe69691
> user: Guido van Rossum
> date: Mon Mar 26 20:35:14 2012 -0700
> summary:
> Approve PEP 411.
> (...)
> -Status: Draft
> +Status: Approved
The pep0 module doesn't accept the "
> +- Richard Oudkerk was given push privileges on Apr 29 2012 by Antoine Pitrou
> + on recommendation by Charles-François Natali and Jesse Noller, for various
> + contributions to multiprocessing (and original authorship of
> + multiprocessing's predecessor, the processing package).
Could one o
On 5/4/2012 1:14 AM, benjamin.peterson wrote:
> http://hg.python.org/cpython/rev/b0deafca6c02
> changeset: 76743:b0deafca6c02
> user:Benjamin Peterson
> date:Fri May 04 01:14:03 2012 -0400
> summary:
> avoid unitialized memory
>
> files:
> Modules/posixmodule.c | 2 +-
> 1
benjamin.peterson wrote:
> summary:
> avoid unitialized memory
>
> diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
> --- a/Modules/posixmodule.c
> +++ b/Modules/posixmodule.c
> @@ -3576,7 +3576,7 @@
> split_py_long_to_s_and_ns(PyObject *py_long, time_t *s, long *ns)
> {
> int
1 - 100 of 2461 matches
Mail list logo
