On Fri, 25 Nov 2011 08:38:48 +0200
Eli Bendersky wrote:
>
> Just to be clear, there were two separate issues raised here. One is the
> speed regression of readinto() from 2.7 to 3.2, and the other is the
> relative slowness of justread() in 3.3
>
> Regarding the second, I'm not sure it's an issu
On Fri, 25 Nov 2011 20:34:21 +1100
Matt Joiner wrote:
>
> It's Python 3.2. I tried it for larger files and got some interesting results.
>
> readinto() for 10MB files, reading 10MB all at once:
>
> readinto/2.7 100 loops, best of 3: 8.6 msec per loop
> readinto/3.2 10 loops, best of 3: 29.6 mse
On Fri, 25 Nov 2011 22:37:49 +1100
Matt Joiner wrote:
> On Fri, Nov 25, 2011 at 10:04 PM, Antoine Pitrou wrote:
> > On Fri, 25 Nov 2011 20:34:21 +1100
> > Matt Joiner wrote:
> >>
> >> It's Python 3.2. I tried it for larger files and got some interesting
On Fri, 25 Nov 2011 12:37:59 -0500
Brett Cannon wrote:
> On Thu, Nov 24, 2011 at 07:46, Nick Coghlan wrote:
>
> > On Thu, Nov 24, 2011 at 10:20 PM, Maciej Fijalkowski
> > wrote:
> > > The problem is not with maintaining the modified directory. The
> > > problem was always things like changing i
On Tue, 29 Nov 2011 00:19:50 +0900
"Stephen J. Turnbull" wrote:
>
> Deprecated features are pretty much irrelevant to the height of the
> bar for new features. The problem is that there are a limited number
> of folks doing long term maintenance of the standard library, and an
> essentially unli
Hi,
On Mon, 28 Nov 2011 01:30:53 -0800
Raymond Hettinger wrote:
>
> On Oct 24, 2011, at 5:58 AM, Ezio Melotti wrote:
>
> > Hi,
> > our current deprecation policy is not so well defined (see e.g. [0]), and
> > it seems to me that it's something like:
> > 1) deprecate something and add a Depre
On Tue, 29 Nov 2011 14:46:06 +0200
Petri Lehtinen wrote:
> Michael Foord wrote:
> > We tend to see 3.2 -> 3.3 as a "major version" increment, but that's
> > just Python's terminology.
>
> Even though (in the documentation) Python's version number components
> are called major, minor, micro, relea
On Tue, 29 Nov 2011 23:36:58 +0100
nadeem.vawda wrote:
> http://hg.python.org/cpython/rev/74d182cf0187
> changeset: 73794:74d182cf0187
> user:Nadeem Vawda
> date:Wed Nov 30 00:25:06 2011 +0200
> summary:
> Issue #6715: Add module for compression using the LZMA algorithm.
Cong
On Thu, 1 Dec 2011 01:31:14 +1100
Matt Joiner wrote:
>
> However given advances in locking and garbage collection in the last
> decade, what attempts have been made recently to try these new ideas
> out? In particular, how unlikely is it that all the thread safe
> primitives, global contexts, and
Hello,
I notice that some FAQs are not only outdated but seem to favour a
writing style that's quite lengthy and full of anecdotal details.
It seems to me that there is value in giving terse answers in FAQs (we
have - or should have - reference documentation where things are
explained in more det
On Sat, 3 Dec 2011 21:39:03 +0100
Antoine Pitrou wrote:
>
> One primary example is the performance question:
> file:///home/antoine/cpython/32/Doc/build/html/faq/programming.html#my-program-is-too-slow-how-do-i-speed-it-up
Woohoo. This should of course be:
http://docs.python.or
On Fri, 09 Dec 2011 00:16:02 +0100
victor.stinner wrote:
>
> +.. c:function:: PyObject* PyUnicode_Copy(PyObject *unicode)
> +
> + Get a new copy of a Unicode object.
> +
> + .. versionadded:: 3.3
I'm not sure I understand. Why would you make a copy of an immutable
object?
___
On Thu, 8 Dec 2011 19:52:28 -0500
Glyph wrote:
> Zooming back in to the actual issue this thread is about, I think the
> u""-vs-"" issue is a bit of a red herring, because the _real_ problem here is
> that 2to3 is slow and buggy and so migration efforts are starting to work
> around it, and the
On Fri, 9 Dec 2011 15:30:36 +1000
Nick Coghlan wrote:
>
> Or, alternatively, you use 'six' (or a similar compatibility module)
> and ensure unicode at runtime, using native or binary strings
> otherwise:
>
> --
> from six import u
> foo = u("this is a Unicode string in both Python 2.x an
Mostly uninformed +1 to Stefan's suggestions from me.
Regards
Antoine.
On Fri, 09 Dec 2011 09:02:35 +0100
Stefan Behnel wrote:
> Hi everyone,
>
> I think Py3.3 would be a good milestone for cleaning up the stdlib support
> for XML. Note upfront: you may or may not know me as the maintainer
On Fri, 9 Dec 2011 15:41:40 +1000
Nick Coghlan wrote:
> On Fri, Dec 9, 2011 at 3:33 PM, Chris McDonough wrote:
> > Even if it weren't slow, I still wouldn't use it to automatically
> > convert code at install time; a single codebase is easier to reason
> > about, and easier to support. Users sen
On Fri, 9 Dec 2011 14:42:43 +
Michael Foord wrote:
>
> Whilst I don't agree with all of his complaints, he makes a fair point about
> the re module Unicode support. It seems that the specific issue he has could
> be fixed by accepting the re module improvement / overhaul implemented by
> m
On Fri, 09 Dec 2011 17:38:56 +0100
Éric Araujo wrote:
> Hi,
>
> When running 2to3 from a setup.py script, does it run on the whole
> codebase or only files that are found newer by the make-like
> timestamp-based dependency system? If it’s the former, as some messages
> seem to show (sorry no tim
On Fri, 09 Dec 2011 19:51:14 +0100
Victor Stinner wrote:
> On 09/12/2011 01:35, Antoine Pitrou wrote:
> > On Fri, 09 Dec 2011 00:16:02 +0100
> > victor.stinner wrote:
> >>
> >> +.. c:function:: PyObject* PyUnicode_Copy(PyObject *unicode)
> >> +
&
Dear Cedric,
I'm guessing you drank too much (perhaps you are training for New Year's
Eve), ate some bad sausages or are simply very self-complacent.
python-dev is not the place where to post long unstructured ramblings
with no practical value. Consider writing on your personal blog
instead.
Tha
On Sat, 10 Dec 2011 20:40:17 +0100
lars.gustaebel wrote:
>
> The :mod:`tarfile` module makes it possible to read and write tar
> -archives, including those using gzip or bz2 compression.
> +archives, including those using gzip, bz2 and lzma compression.
> (:file:`.zip` files can be read and wr
Le dimanche 11 décembre 2011 à 23:44 +0100, "Martin v. Löwis" a écrit :
> Am 09.12.2011 20:32, schrieb Antoine Pitrou:
> > On Fri, 09 Dec 2011 19:51:14 +0100
> > Victor Stinner wrote:
> >> On 09/12/2011 01:35, Antoine Pitrou wrote:
> >>> On Fri, 0
On Tue, 13 Dec 2011 15:28:31 +0100
"Laurence Rowe" wrote:
>
> The approach that most people seem to have settled on for porting
> libraries to Python 3 is to make a single codebase that is compatible with
> both Python 2 and Python 3, perhaps making use of the six library.
Do you have eviden
On Tue, 13 Dec 2011 14:02:45 -0500
PJ Eby wrote:
>
> Among other things, it means that:
>
> * There's only one codebase
> * If the conversion isn't perfect, you only have to fix it once
> * Line numbers are the same
> * There's no conversion step slowing down development
>
> So, I expect that i
On Tue, 13 Dec 2011 23:51:00 -0500
Terry Reedy wrote:
> So by analogy, reserved type value would be ignored, neither corrupting
> data or raising errors, until put in use.
That simply doesn't make sense.
Regards
Antoine.
___
Python-Dev mailing list
On Thu, 15 Dec 2011 10:31:08 + (UTC)
Vinay Sajip wrote:
> In response to http://bugs.python.org/issue13516 I'm thinking of implementing
> some changes in the rotating file handlers, as outlined here:
>
> http://plumberjack.blogspot.com/2011/12/improved-flexibility-for-log-file.html
>
> The c
On Thu, 15 Dec 2011 22:18:18 +
Mark Shannon wrote:
>
> For the gcbench benchmark (from unladen swallow),
> cpython with the new dict is about 9% faster and, more importantly,
> reduces memory use from 99 Mbytes to 61Mbytes (a 38% reduction).
>
> All tests were done on my ancient 32 bit intel
On Sun, 18 Dec 2011 13:09:16 +1300
Greg Ewing wrote:
> Matt Joiner wrote:
> > ಠ_ಠ
>
> What's up with these ?_? messages?
>>> print(ascii("ಠ_ಠ"))
'\u0ca0_\u0ca0'
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailm
On Fri, 16 Dec 2011 21:32:44 +
Mark Shannon wrote:
>
> > per-instance attributes, it just forces them all to keep resizing up,
> > even though individual instances would be small with the current dict.
> There is a cut-off point, at the moment it's quite unsophisticated about
> how it does t
On Mon, 19 Dec 2011 22:42:43 +0100
benjamin.peterson wrote:
> http://hg.python.org/cpython/rev/d85efd73b0e1
> changeset: 74088:d85efd73b0e1
> branch: 3.2
> parent: 74082:71e5a083f9b1
> user:Benjamin Peterson
> date:Mon Dec 19 16:41:11 2011 -0500
> summary:
> don't me
Hello,
The include file (unicodeobject.h) seems to imply that some pure ASCII
strings can be non-compact, but I don't understand how that can happen.
Besides, the following comment also seems wrong:
- compact:
* structure = PyCompactUnicodeObject
* test: PyUnicode_IS_A
Le mardi 20 décembre 2011 à 12:01 +0200, Maciej Fijalkowski a écrit :
>
> If this documentation is to be used by other python implementations,
> then mentions of performance are outright harmful, since the
> performance characteristics differ quite drastically. Written in C is
> also not a part o
On Tue, 20 Dec 2011 11:14:15 +0100
Dirkjan Ochtman wrote:
> On Tue, Dec 20, 2011 at 11:08, Antoine Pitrou wrote:
> >> If this documentation is to be used by other python implementations,
> >> then mentions of performance are outright harmful, since the
> >> perf
On Tue, 20 Dec 2011 05:27:41 -0500
Terry Reedy wrote:
> >
> > I disagree with this change. Knowing that they are written in C is
> > important when deciding to pass them to e.g. sort() or sorted(),
> > because you know it will be faster than an arbitrary pure Python
> > function.
> >
> > You could
Le mardi 20 décembre 2011 à 10:57 -0500, Benjamin Peterson a écrit :
> 2011/12/20 Antoine Pitrou :
> > On Mon, 19 Dec 2011 22:42:43 +0100
> > benjamin.peterson wrote:
> >> http://hg.python.org/cpython/rev/d85efd73b0e1
> >> changeset: 74088:d85efd73b0e1
On Wed, 21 Dec 2011 07:16:06 +
Chris Withers wrote:
> What's the python-dev view on this?
Python 2.5 is not supported by *us* anymore (*). Anyone still using it
therefore relies on their OS vendor to apply potential security
patches and other important fixes.
Library authors can of course ch
On Thu, 22 Dec 2011 09:44:32 +
Tim Wintle wrote:
>
> 2.5 apps are the speed-critical ones. Our tests showed the performance
> was different enough between 2.5 and 2.6 for me to not update.
Really? Where's the regression?
Regards
Antoine.
___
Py
Hello,
Today I've modified the WSGI configuration at hg.python.org. If you
notify anything wrong (e.g. when cloning a repository), please tell me.
For the curious: http://mercurial.selenic.com/bts/issue2595
Regards
Antoine.
___
Python-Dev mailing l
On Thu, 29 Dec 2011 03:55:22 +0100
Christian Heimes wrote:
>
> I've been dealing with web stuff and security for almost a decade. I've
> seen far worse attack vectors. This one can easily be solved with a
> couple of lines of Python code. For example Application developers can
> limit the maximum
On Thu, 29 Dec 2011 04:04:17 +0100
Christian Heimes wrote:
> Am 29.12.2011 02:37, schrieb Jesse Noller:
> > Back up link for the PDF:
> > http://dl.dropbox.com/u/1374/2007_28C3_Effective_DoS_on_web_application_platforms.pdf
> >
> > Ocert disclosure:
> > http://www.ocert.org/advisories/ocert-2011-
On Thu, 29 Dec 2011 14:32:21 +0100
Christian Heimes wrote:
> Am 29.12.2011 13:57, schrieb Armin Ronacher:
> > Hi,
> >
> > Something I should add to this now that I thought about it a bit more:
> >
> > Assuming this should be fixed on a language level the solution would
> > probably be to salt ha
On Thu, 29 Dec 2011 11:25:03 +
Mark Shannon wrote:
> >
> > Also, randomizing the hash wreaks havoc on doctests, book examples
> > not matching actual dict reprs, and on efforts by users to optimize
> > the insertion order into dicts with frequent lookups.
>
> The docs clearly state that the
On Thu, 29 Dec 2011 13:57:07 +0100
Armin Ronacher wrote:
>
> - Option c: Random salt at runtime
> + Easy to implement
> - impossible to synchronize
> - breaks unittests in the same way as a compiled in salt would do
This option would have my preference. I don't think hash() was ever
meant
On Fri, 30 Dec 2011 13:29:36 -0600
Brian Curtin wrote:
>
> Can we expect that readers on Windows know how os.symlink works, or
> should the stipulations of os.symlink usage also be laid out or at
> least linked to from there?
I assume it won't make a difference in real life, since symlinks are
q
On Sat, 31 Dec 2011 16:56:00 -0700
Guido van Rossum wrote:
> ISTM the only reasonable thing is to have a random seed picked very early
> in the process, to be used to change the hash() function of
> str/bytes/unicode (in a way that they are still compatible with each other).
Do str and bytes stil
On Sun, 01 Jan 2012 16:48:32 +0100
Christian Heimes wrote:
> The talkers claim and have shown that it's too easy to pre-calculate
> collisions with hashing algorithms similar to DJBX33X / DJBX33A. It
> might be a good idea to change the hashing algorithm, too. Paul as
> listed some new algorithms.
On Sun, 01 Jan 2012 16:56:19 +0100
Christian Heimes wrote:
> Am 01.01.2012 05:11, schrieb Antoine Pitrou:
> > On Sat, 31 Dec 2011 16:56:00 -0700
> > Guido van Rossum wrote:
> >> ISTM the only reasonable thing is to have a random seed picked very early
> >> in
Le dimanche 01 janvier 2012 à 17:34 +0100, Christian Heimes a écrit :
> Am 01.01.2012 17:09, schrieb Antoine Pitrou:
> > On Sun, 01 Jan 2012 16:48:32 +0100
> > Christian Heimes wrote:
> >> The talkers claim and have shown that it's too easy to pre-calculate
> >&
On Mon, 02 Jan 2012 02:04:38 +0100
Christian Heimes wrote:
>
> PS: Something is wrong with your email client. Every of your replies
> starts a new thread for me.
Same here.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://m
On Sun, 1 Jan 2012 21:55:52 -0800
Paul McMillan wrote:
>
> This is similar to the change proposed by Christian Heimes.
>
> Most importantly, I moved the xor with r[x % len_r] down a line.
> Before, it wasn't being applied to the last character.
Shouldn't it be r[i % len(r)] instead?
(refer to y
On Mon, 2 Jan 2012 14:44:49 +1000
Nick Coghlan wrote:
> I've been having an occasional argument with Benjamin regarding braces
> in 4-line if statements:
>
> if (cond)
> statement;
> else
> statement;
>
> vs.
>
> if (cond) {
> statement;
> } else {
> statement;
> }
Go
On Mon, 2 Jan 2012 14:44:49 +1000
Nick Coghlan wrote:
>
> He keeps leaving them out, I occasionally tell him they should always
> be included (most recently this came up when we gave conflicting
> advice to a patch contributor).
Oh, by the way, this is also why I avoid arguing too much about sty
On Mon, 02 Jan 2012 16:00:50 +0100
benjamin.peterson wrote:
> http://hg.python.org/cpython/rev/d5cda62d0f8c
> changeset: 74236:d5cda62d0f8c
> user:Benjamin Peterson
> date:Mon Jan 02 09:00:30 2012 -0600
> summary:
> fix some possible refleaks from PyUnicode_READY error conditi
On Tue, 03 Jan 2012 14:18:34 +0100
Christian Heimes wrote:
>
> I suggest Python/random.c as source file and Python/pyrandom.h as header
> file. Comments?
Looks good on the principle. The API names for MT are a bit ugly.
> The RNG should be suitable for cryptography.
Sounds like too strong a re
On Tue, 3 Jan 2012 22:17:06 +0100
Victor Stinner wrote:
> A randomized hash doesn't need cryptographic RNG (which are slow and
> need a lot of new code), and the new hash function should maybe not be
> cryptographic. We need to make the DoS more expensive for the
> attacker, but we don't need to a
> +.. c:function:: int PyUnicode_Fill(PyObject *unicode, Py_ssize_t start, \
> +Py_ssize_t length, Py_UCS4 fill_char)
> +
> + Fill a string with a character: write *fill_char* into
> + ``unicode[start:start+length]``.
> +
> + Fail if *fill_char* is bigger than the str
On Tue, 03 Jan 2012 23:21:30 +0100
"Martin v. Löwis" wrote:
> > Have you read the following sentence:
> >
> > “Since some platforms may not have /dev/urandom, we need a PRNG in the
> > core, too. I therefore propose to move the Mersenne twister from
> > randommodule.c into the core, too.”
>
> I
On Wed, 4 Jan 2012 09:59:15 +0200
Maciej Fijalkowski wrote:
>
> Is it *really* a security issue? We knew all along that dicts are
> O(n^2) in worst case scenario, how is this suddenly a security
> problem?
Because it has been shown to be exploitable for malicious purposes?
Regards
Antoine.
_
On Thu, 5 Jan 2012 15:26:27 +1100
Andrew Bennetts wrote:
>
> I don't think that's news either.
> http://mail.python.org/pipermail/python-dev/2003-May/035907.html and
> http://twistedmatrix.com/pipermail/twisted-python/2003-June/004339.html for
> instance show that in 2003 it was clearly known to
On Thu, 05 Jan 2012 13:46:52 +
Mark Shannon wrote:
>
> Should I:
>
> 1. Submit one big bug report?
>
> 2. Submit a bug report for each "failing" test separately?
I would say a separate bug report for each failing test file, i.e. one
report for test_dis, one for test_email etc.
Hope this do
On Thu, 5 Jan 2012 19:34:13 +0200
Maciej Fijalkowski wrote:
>
> Just to make things clear - stdlib itself has 1/64 of tests relying on
> dict order. Changing dict order in *older* pythons will break
> everyone's tests and some peoples code.
Breaking tests is not a problem: they are typically not
On Thu, 05 Jan 2012 22:40:58 +0100
Christian Heimes wrote:
> Am 05.01.2012 21:45, schrieb Barry Warsaw:
> > This sounds like a reasonable compromise for all stable Python releases. It
> > can be turned on by default for Python 3.3. If you also make the default
> > setting easy to change (i.e. pa
On Thu, 5 Jan 2012 15:02:42 -0700
Eric Snow wrote:
> 2012/1/5 Charles-François Natali :
> > Hi,
> >
> > Issue #13697 (http://bugs.python.org/issue13697) deals with a problem
> > with the Python version of threading.RLock (a signal handler which
> > tries to acquire the same RLock is called right
On Fri, 06 Jan 2012 01:50:00 +0100
Christian Heimes wrote:
> Am 06.01.2012 01:34, schrieb Nick Coghlan:
> > On Fri, Jan 6, 2012 at 10:07 AM, Steven D'Aprano
> > wrote:
> >> Surely the way to verify the behaviour is to run this from the shell:
> >>
> >> python -c print(hash("abcde"))
> >>
> >> tw
Hi Paul,
> I'm a little slow in responding to
> http://blog.python.org/2011/05/python-33-to-drop-support-for-os2.html,
> but I'm interested in stepping up to help maintain OS/2 support in
> Python 3.3 and above.
>
> I've been building Python 2.x for a while, and currently have binaries
> of
On Sat, 07 Jan 2012 06:28:00 +1030
Paul Smedley wrote:
>
> I now have a dll and exe - however when it tried to build the modules,
> it dies with:
> Could not find platform independent libraries
> Could not find platform dependent libraries
> Consider setting $PYTHONHOME to [:]
> Fatal Python e
On Sat, 07 Jan 2012 18:57:41 +0100
"Martin v. Löwis" wrote:
> For example, everything
> related to subprocess creation would not work; none of the
> byte-oriented file API seems to be present, and a number of file
> operation functions are absent as well (such as MoveFile).
When you say MoveFile
> > When you say MoveFile is absent, is MoveFileEx supported instead?
>
>WinRT strongly prefers asynchronous methods for all lengthy
> operations. The most likely call to use for moving files is
> StorageFile.MoveAsync.
> http://msdn.microsoft.com/en-us/library/windows/apps/br227219.aspx
How
On Mon, 09 Jan 2012 02:01:46 +0100
Christian Heimes wrote:
>
> I tried to compare the py3k baseline with my randomhash branch but the
> benchmark suite is failing.
>
> I've follewed the instruction
For the record, you don't really need this. Just run the "2n3"
benchmark set (it works under both
On Mon, 09 Jan 2012 21:58:29 +0100
terry.reedy wrote:
>
> -Different branches are used at a time to represent different *minor versions*
> -in which development is made. All development should be done **first** in
> the
> -:ref:`in-development ` branch, and selectively backported
> -to other b
On Tue, 10 Jan 2012 08:49:04 +
Rob Cliffe wrote:
> But "minor version" and "major version" are readily understandable to
> the general reader, e.g. me, whereas "feature release" and "release
> series" I find are not. Couldn't the first two terms be defined once
> and then used throughout?
On Tue, 10 Jan 2012 11:57:03 -0500
Glyph wrote:
>
> Whatever your personal feelings, there is a precedent established in the API:
>
> >>> sys.version_info.major
> 2
> >>> sys.version_info.minor
> 7
> >>> sys.version_info.micro
> 1
>
> This strikes me as the most authoritative definition of the
On Wed, 11 Jan 2012 02:09:02 +0100
"Martin v. Löwis" wrote:
> Am 10.01.2012 18:15, schrieb Matt Joiner:
> > I suspect it actually would fix the confusion. "dev" usually means
> > development, not "core implementation development". People float past
> > looking for dev help... python-dev. Python-l
On Wed, 11 Jan 2012 12:25:46 +1000
Nick Coghlan wrote:
> When discussing http://bugs.python.org/issue13734, Charles-François
> noted that when os.walk() is called with "followlinks=False", symlinks
> to directories are still included in the "subdirs" list rather than
> the "files" list.
>
> This
On Fri, 13 Jan 2012 17:00:57 +0100
Xavier Morel wrote:
> FWIW this is not restricted to Linux (the same behavior change can
> be observed in OSX), and the script is overly complex you can expose
> the change with 3 lines
>
> import sys
> sys.stdout.write('promt>')
> sys.stdin.read(1)
On Fri, 13 Jan 2012 22:14:43 +1000
Nick Coghlan wrote:
> I marked PEP 380 as Final this evening, after pushing the tested and
> documented implementation to hg.python.org:
> http://hg.python.org/cpython/rev/d64ac9ab4cd0
I don't know if this is supposed to work, but the exception looks wrong:
>>>
On Thu, 12 Jan 2012 18:57:42 -0800
Guido van Rossum wrote:
> Hm... I started out as a big fan of the randomized hash, but thinking more
> about it, I actually believe that the chances of some legitimate app having
> >1000 collisions are way smaller than the chances that somebody's code will
> brea
On Sat, 14 Jan 2012 04:45:57 +0100
mar...@v.loewis.de wrote:
> > What an implementation looks like:
> >
> > http://pastebin.com/9ydETTag
> >
> > some stuff to be filled in, but this is all that is really required.
>
> I think this statement (and the patch) is wrong. You also need to change
> the
On Sat, 14 Jan 2012 13:55:22 +1100
Steven D'Aprano wrote:
> On 14/01/12 12:58, Gregory P. Smith wrote:
>
> > I do like *randomly seeding the hash*. *+1*. This is easy. It can easily be
> > back ported to any Python version.
> >
> > It is perfectly okay to break existing users who had anything dep
On Sun, 15 Jan 2012 17:46:36 +0100
Stefan Behnel wrote:
> Guido van Rossum, 15.01.2012 17:10:
> > On Sun, Jan 15, 2012 at 6:30 AM, Stefan Behnel wrote:
> >> Terry Reedy, 14.01.2012 06:43:
> >>> On 1/13/2012 8:58 PM, Gregory P. Smith wrote:
> >>>
> It is perfectly okay to break existing users
On Mon, 16 Jan 2012 11:17:42 -0500
Brett Cannon wrote:
> Is the change to the pyc format big enough news to go into the release PEP?
> Or should that just be a "What's New" topic?
"What's New" sounds enough to me. The change doesn't enable any new
feature, it just makes an issue much less likely
ucing long-term support versions
Version: $Revision$
Last-Modified: $Date$
Author: Antoine Pitrou ,
Georg Brandl ,
Barry Warsaw
Status: Draft
Type: Process
Content-Type: text/x-rst
Created: 2012-01-12
Post-History:
Resolution: TBD
Abstract
Finding a release cycle for an
On Tue, 17 Jan 2012 21:59:28 +0100
"Martin v. Löwis" wrote:
> I'd like to propose a different approach to seeding the string hashes:
> only do so for dictionaries involving only strings, and leave the
> tp_hash slot of strings unchanged.
I think Python 3 would be better with a clean fix (all hash
Hello,
On Wed, 18 Jan 2012 10:04:19 +1100
Matt Joiner wrote:
> If minor/feature releases are introducing breaking changes perhaps it's
> time to adopt accelerated major versioning schedule.
The PEP doesn't propose to accelerate compatibility breakage. So I don't
think a change in numbering is r
On Tue, 17 Jan 2012 18:29:11 -0500
Terry Reedy wrote:
>
> To me, as I understand the proposal, the title is wrong. Our current
> feather releases already are long-term support versions. They get bugfix
> releases at close to 6 month intervals for 1 1/2 -2 years and security
> fixes for 3 years
On Wed, 18 Jan 2012 07:52:20 +
Paul Moore wrote:
> On 18 January 2012 07:46, Georg Brandl wrote:
> >> But I am dubious that releases that are obsolete in 6 months and lack
> >> 3rd party support will see much production use.
> >
> > Whether people would use the releases is probably something
On Wed, 18 Jan 2012 11:37:08 +0900
"Stephen J. Turnbull" wrote:
> > availability of release management volunteers,
>
> Dramatic increase here. It may look like RM is not so demanding --
> run a few scripts to put out the alphas/betas/releases. But the RM
> needs to stay on top of breaking news
Le mercredi 18 janvier 2012 à 21:26 +1000, Nick Coghlan a écrit :
> I'm also wholly in agreement with Ezio that using the
> same versioning scheme for both full releases and interim releases is
> thoroughly confusing for users
It's a straight-forward way to track the feature support of a release
Le mercredi 18 janvier 2012 à 21:48 +0900, Stephen J. Turnbull a écrit :
> My claim is that I don't expect much uptake if you
> don't do close to as many of what are called "alpha" and "beta" tests
> on python-dev as are currently done.
You claim people won't use stable releases because of not en
Le jeudi 19 janvier 2012 à 00:25 +0900, Stephen J. Turnbull a écrit :
>
> > You claim people won't use stable releases because of not enough
> > alphas? That sounds completely unrelated.
>
> Surely testing is related to user perceptions of stability. More
> testing helps reduce bugs in relea
On Thu, 19 Jan 2012 01:06:07 +1000
Nick Coghlan wrote:
> On Wed, Jan 18, 2012 at 2:31 PM, wrote:
> > results for 12de1ad1cee8 on branch "default"
> >
> >
> > test_capi leaked [2008, 2008, 2008] references, sum=6024
>
> Yikes, you weren't kidding abou
On Wed, 18 Jan 2012 11:14:50 -0500
Brett Cannon wrote:
> On Wed, Jan 18, 2012 at 10:56, Antoine Pitrou wrote:
>
> > On Thu, 19 Jan 2012 01:06:07 +1000
> > Nick Coghlan wrote:
> > > On Wed, Jan 18, 2012 at 2:31 PM, wrote:
> > > > resu
On Wed, 18 Jan 2012 11:39:42 -0500
Brett Cannon wrote:
> >
> > > We could then maybe try to get some
> > > people pound on this at the PyCon sprints. Otherwise I'm reluctant to
> > skip
> > > it since they are legitimate leaks that should be get fixed.
> >
> > Well it's the old well-known issue wi
Hello Dirkjan,
On Wed, 18 Jan 2012 18:32:22 +0100
Dirkjan Ochtman wrote:
> On Tuesday, January 17, 2012, Antoine Pitrou wrote:
> > We would like to propose the following PEP to change (C)Python's release
> > cycle. Discussion is welcome, especially from people involve
Well, they should be fixed now :-)
Regards
Antoine.
On Wed, 18 Jan 2012 17:42:15 +0100
Antoine Pitrou wrote:
> On Wed, 18 Jan 2012 11:39:42 -0500
> Brett Cannon wrote:
> > >
> > > > We could then maybe try to get some
> > > > people pound on t
On Thu, 19 Jan 2012 11:12:06 +1100
Steven D'Aprano wrote:
> Antoine Pitrou wrote:
> > Le jeudi 19 janvier 2012 à 00:25 +0900, Stephen J. Turnbull a écrit :
> >> > You claim people won't use stable releases because of not enough
> >> > alphas? That so
On Thu, 19 Jan 2012 11:03:15 +1000
Nick Coghlan wrote:
>
> 1. I believe the PEP currently proposes just taking the "no more than
> 9" limit off the minor version of the language. Feature releases would
> just come out every 6 months, with every 4th release flagged as a
> language release.
With t
On Wed, 18 Jan 2012 20:31:38 -0700
Eric Snow wrote:
> >
> > Should I create a bug report?
>
> http://bugs.python.org/issue12773 :)
Well done Eric :)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
On Fri, 20 Jan 2012 13:50:18 +0100
Victor Stinner wrote:
> > The main issue with that approach is that it allows a new kind of attack.
> >
> > An attacker now needs to find 1000 colliding keys, and submit them
> > one-by-one into a database. The limit will not trigger, as those are
> > just datab
On Fri, 20 Jan 2012 12:57:45 +
Paul Moore wrote:
> On 20 January 2012 03:57, Brian Curtin wrote:
> >> FWIW, it might well be that I can't be available for the 3.3 final
> >> release (I haven't finalized my vacation schedule yet for August).
> >
> > In the interest of not having Windows releas
4201 - 4300 of 4909 matches
Mail list logo
