On Fri, 20 Jan 2012 17:17:24 +0100
Victor Stinner wrote:
> > So I still think we should ditch the paranoia about dictionary order
> > changing,
> > and fix this without counting.
>
> The randomized hash has other issues:
>
> - its security is based on its secret, whereas it looks to be easy to
On Sat, 21 Jan 2012 21:51:43 +0100
gregory.p.smith wrote:
> http://hg.python.org/cpython/rev/d01fecadf3ea
> changeset: 74561:d01fecadf3ea
> branch: 3.2
> parent: 74558:03e61104f7a2
> user:Gregory P. Smith
> date:Sat Jan 21 12:31:25 2012 -0800
> summary:
> Avoid the c
On Sat, 21 Jan 2012 23:39:41 +0100
gregory.p.smith wrote:
> http://hg.python.org/cpython/rev/61aa484a3e54
> changeset: 74563:61aa484a3e54
> branch: 3.2
> parent: 74561:d01fecadf3ea
> user:Gregory P. Smith
> date:Sat Jan 21 14:01:08 2012 -0800
> summary:
> Fixes issue
I think this thread is approaching the recursion limit.
Be careful not to blow the stack :)
Regards
Antoine.
On Sun, 22 Jan 2012 20:53:41 +0100
Lennart Regebro wrote:
> On Sun, Jan 22, 2012 at 11:11, Victor Stinner
> wrote:
> >> This seed is chosen randomly at runtime, but cannot
> >> change
On Fri, 27 Jan 2012 15:21:33 +0200
Eli Bendersky wrote:
>
> Following an earlier discussion on python-ideas [1], we would like to
> propose the following PEP for review. Discussion is welcome. The PEP
> can also be viewed in HTML form at
> http://www.python.org/dev/peps/pep-0408/
A big +1 from m
Hello Philippe,
On Fri, 27 Jan 2012 17:09:08 +0100
Philippe Fremy wrote:
>
> According to the PEP, the interface may change betweeen __preview__ and
> final inclusion in stdlib. It would be unwise as a developer to assume
> that a program written for the preview version will work correctly in
>
On Fri, 27 Jan 2012 16:10:51 -0500
Barry Warsaw wrote:
>
> I'm -1 on this as well. It just feels like the completely wrong way to
> stabilize an API, and I think despite the caveats that are explicit in
> __preview__, Python will just catch tons of grief from users and haters about
> API instabi
On Fri, 27 Jan 2012 17:54:14 -0500
Barry Warsaw wrote:
> On Jan 27, 2012, at 10:48 PM, Antoine Pitrou wrote:
>
> >On Fri, 27 Jan 2012 16:10:51 -0500
> >Barry Warsaw wrote:
> >>
> >> I'm -1 on this as well. It just feels like the completely wrong
> I don't consider it mandatory to fix all issues with hash collision.
> In fact, none of the strategies fixes all issues with hash collisions;
> even the hash-randomization solutions only deal with string keys, and
> don't consider collisions on non-string keys.
How so? None of the patches did,
On Sat, 28 Jan 2012 01:53:40 +0100
mar...@v.loewis.de wrote:
>
> > How so? None of the patches did, but I think it was said several times
> > that other types (int, tuple, float) could also be converted to use
> > randomized hashes. What's more, there isn't any technical difficulty in
> > doing so
On Sat, 28 Jan 2012 02:49:40 -0500
Matt Joiner wrote:
> FWIW I'm now -1 for this idea. Stronger integration with PyPI and
> packaging systems is much preferable.
That will probably never happen. "pip install XXX" is the best we
(python-dev and the community) can do. "import some_module" won't
mag
On Sat, 28 Jan 2012 00:09:13 -0500
Scott Dial wrote:
> On 1/27/2012 8:48 PM, Barry Warsaw wrote:
> > The thinking goes like this: if you would normally use an __preview__ module
> > because you can't get approval to download some random package from PyPI,
> > well
> > then your distro probably co
On Sat, 28 Jan 2012 13:14:36 -0500
Barry Warsaw wrote:
> On Jan 28, 2012, at 09:15 AM, Guido van Rossum wrote:
>
> >So I do not support the __preview__ package. I think we're better off
> >flagging experimental modules in the docs than in their name. For the
> >specific case of the regex module,
On Sat, 28 Jan 2012 14:21:18 +0200
Maciej Fijalkowski wrote:
> Hi
>
> Something that's maybe worth mentioning is that the "official" python
> benchmark suite http://hg.python.org/benchmarks/ has a pretty
> incomplete set of benchmarks for python 3 compared to say what we run
> for pypy: https://b
Le samedi 28 janvier 2012 à 10:46 -0800, Mike Meyer a écrit :
> Antoine Pitrou wrote:
>
> >On Sat, 28 Jan 2012 13:14:36 -0500
> >Barry Warsaw wrote:
> >> On Jan 28, 2012, at 09:15 AM, Guido van Rossum wrote:
> >>
> >> >So I do not support the
> >You're proposing that new experimental modules spit warnings when you
> >use them?
>
> To be explicit, when the system loada them.
There are many reasons to import a module, such as viewing its
documentation. And the warning will trigger if the import happens in
non-user code, such as a libra
Le samedi 28 janvier 2012 à 16:03 -0700, Eric Snow a écrit :
> On Sat, Jan 28, 2012 at 3:02 PM, Antoine Pitrou wrote:
> > There are many reasons to import a module, such as viewing its
> > documentation. And the warning will trigger if the import happens in
> > non-user co
Hi,
On Sun, 29 Jan 2012 10:31:48 +
Mark Shannon wrote:
>
> Now that issue 13703 has been largely settled,
> I want to propose my new dictionary implementation again.
> It is a little more polished than before.
>
> https://bitbucket.org/markshannon/hotpy_new_dict
I briefly took a look at y
On Sun, 29 Jan 2012 09:56:11 -0500
Benjamin Peterson wrote:
> 2012/1/29 Mark Shannon :
> > Hi,
> >
> > Now that issue 13703 has been largely settled,
> > I want to propose my new dictionary implementation again.
> > It is a little more polished than before.
>
> If you're serious about changing t
On Sun, 29 Jan 2012 16:42:28 +1000
Nick Coghlan wrote:
> On Sun, Jan 29, 2012 at 1:29 PM, Guido van Rossum wrote:
> > On Sat, Jan 28, 2012 at 5:33 PM, Nick Coghlan wrote:
> >> I'm willing to go along with that (especially given your report of
> >> AppEngine's experience with the "labs" namespace
Hello,
> Well, you can implement threaded code on any machine that support
> indirect branch instructions. Fortunately, GCC supports the
> "label-as-values" feature, which makes it available on any machine
> that supports GCC. My optimizations themselves are portable, and I
> tested them on a Pow
On Mon, 30 Jan 2012 16:26:30 -0500
Brett Cannon wrote:
> Should this end up being used in importlib through _os?
Yes, probably. I hadn't thought about that.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
On Tue, 31 Jan 2012 21:11:37 +1000
Nick Coghlan wrote:
>
> Having a low-level module like os needing to know about higher-level
> types like decimal.Decimal and datetime.datetime (or even timedelta)
> should be setting off all kinds of warning bells.
Decimal is ideally low-level (it's a number),
On Wed, 1 Feb 2012 10:35:08 +1000
Nick Coghlan wrote:
>
> With this approach, API usage might end up looking something like:
>
>>>> time.time()
>1328006975.681211
>>>> time.time(convert=time.as_float)
>1328006975.681211
>>>> time.time(convert=time.as_int)
>1328006979
>
On Wed, 1 Feb 2012 14:08:34 +1000
Nick Coghlan wrote:
> On Wed, Feb 1, 2012 at 12:35 PM, Antoine Pitrou wrote:
> > It strikes me as inelegant to have to do so much typing for something
> > as simple as getting the current time. We should approach the
> > simplicity of ``time
On Thu, 2 Feb 2012 23:07:28 +1000
Nick Coghlan wrote:
>
> We can't add new fields to the stat tuple anyway - it breaks tuple
> unpacking.
I don't think that's true. The stat tuple already has a varying number
of fields: http://docs.python.org/dev/library/os.html#os.stat
“For backward compatibil
On Thu, 2 Feb 2012 14:10:14 +0100
Victor Stinner wrote:
> > Even if I like the idea, I don't think that we need all this machinery
> > to support nanosecond resolution. I should maybe forget my idea of
> > using datetime.datetime or datetime.timedelta, or only only support
> > int, float and decim
On Thu, 2 Feb 2012 15:09:41 +0100
Victor Stinner wrote:
> > Why int? That doesn't seem to bring anything.
>
> It helps to deprecate/replace os.stat_float_times(), which may be used
> for backward compatibility (with Python 2.2 ? :-)).
I must admit I don't understand the stat_float_times documen
On Wed, 1 Feb 2012 09:50:55 -0800
Guido van Rossum wrote:
> On Wed, Feb 1, 2012 at 9:13 AM, Hans Mulder wrote:
> > On 30/01/12 00:30:14, Steven D'Aprano wrote:
> >>
> >> Mark Shannon wrote:
> >>>
> >>> Antoine Pitrou wrote:
> >
>
On Thu, 2 Feb 2012 16:25:25 +0100
Victor Stinner wrote:
> > That said, I don't understand why we couldn't simply deprecate
> > stat_float_times() right now. Having an option for integer timestamps
> > is pointless, you can just call int() on the result if you want.
>
> So which API do you propose
On Fri, 3 Feb 2012 11:04:14 -0800
Jeffrey Yasskin wrote:
> On Thu, Feb 2, 2012 at 4:59 PM, Nick Coghlan wrote:
> > datetime.datetime
> >
> > - real problem with the idea is that not all timestamps can be easily
> > made absolute (e.g. some APIs may return "time since system started"
> > or "time
On Fri, 3 Feb 2012 19:19:21 -0500
Benjamin Peterson wrote:
> 2012/2/3 Ethan Furman :
> > Good news! PEP 409 has been accepted!
>
> It may be too late for this, but I find the whole Ellipsis business
> most unpleasant. Why not just have a extra attribute on exception
> objects like __chain__ = Fa
On Mon, 6 Feb 2012 09:57:56 -0500
Brett Cannon wrote:
> Thanks for any help people can provide me on this now 5 year quest to get
> this work finished.
Do you have any plan to solve the performance issue?
$ ./python -m timeit -s "import sys; mod='struct'" \
"__import__(mod); del sys.modules[mo
On Mon, 6 Feb 2012 20:49:48 +0100
Antoine Pitrou wrote:
> On Mon, 6 Feb 2012 09:57:56 -0500
> Brett Cannon wrote:
> > Thanks for any help people can provide me on this now 5 year quest to get
> > this work finished.
>
> Do you have any plan to solve the performance i
On Mon, 6 Feb 2012 22:57:46 +0100
Victor Stinner wrote:
>
> >> - id->object = PyUnicode_DecodeUTF8Stateful(id->string,
> >> - strlen(id->string),
> >> - NULL, NULL);
> >> + id->object =
On Tue, 7 Feb 2012 15:07:24 -0500
Brett Cannon wrote:
>
> Now I'm going to be upfront and say I really did not want to have this
> performance conversation now as I have done *NO* profiling or analysis of
> the algorithms used in importlib in order to tune performance (e.g. the
> function that ha
On Tue, 7 Feb 2012 17:24:21 -0500
Brett Cannon wrote:
>
> IOW you want the sys.modules case fast, which I will never be able to match
> compared to C code since that is pure execution with no I/O.
Why wouldn't continue using C code for that? It's trivial (just a dict
lookup).
Regards
Antoine.
On Tue, 7 Feb 2012 17:16:18 -0500
Brett Cannon wrote:
>
> > > IOW I really do not look forward to someone saying "importlib is so much
> > > slower at importing a module containing ``pass``" when (a) that never
> > > happens, and (b) most programs do not spend their time importing but
> > > inst
On Wed, 8 Feb 2012 11:11:07 +
Paul Moore wrote:
> On 8 February 2012 09:49, Eli Bendersky wrote:
> >> I concur. It's important that we consider Fredrik's ownership of the
> >> modules, but if he fails to reply to email and doesn't update his
> >> repositories, there should be enough cause for
Le mercredi 08 février 2012 à 11:01 -0500, Brett Cannon a écrit :
>
>
> On Tue, Feb 7, 2012 at 17:42, Antoine Pitrou
> wrote:
> On Tue, 7 Feb 2012 17:24:21 -0500
> Brett Cannon wrote:
> >
> > IOW you want the sys.modules
On Wed, 8 Feb 2012 11:07:10 -0500
Brett Cannon wrote:
> >
> > > > > So, if there is going to be some baseline performance target I need
> > to
> > > > hit
> > > > > to make people happy I would prefer to know what that (real-world)
> > > > > benchmark is and what the performance target is going t
On Thu, 9 Feb 2012 08:43:02 +0200
Simon Cross wrote:
> On Thu, Feb 9, 2012 at 2:35 AM, Steven D'Aprano wrote:
> > Simon Cross wrote:
> >>
> >> I think I'm -1 on a "locale" encoding because it refers to different
> >> actual encodings depending on where and when it's run, which seems
> >> surpris
On Thu, 9 Feb 2012 17:00:04 -0500
PJ Eby wrote:
> On Thu, Feb 9, 2012 at 2:53 PM, Mike Meyer wrote:
>
> > For those of you not watching -ideas, or ignoring the "Python TIOBE
> > -3%" discussion, this would seem to be relevant to any discussion of
> > reworking the import mechanism:
> >
> > http:
On Fri, 10 Feb 2012 16:06:15 +0200
Eli Bendersky wrote:
>
> Following the intensive and fruitful discussion of the (now rejected)
> PEP 408
> (http://mail.python.org/pipermail/python-dev/2012-January/115850.html),
> we've drafted PEP 411 to summarize the conclusions with regards to the
> process
Hello Mark,
I think the PEP should explain what happens when a keys table needs
resizing when setting an object's attribute.
Reading the implementation, it seems the sharing can disappear
definitely, which seems a bit worrying.
Regards
Antoine.
On Wed, 08 Feb 2012 19:18:14 +
Mark Shannon
On Sun, 12 Feb 2012 19:04:30 +1000
Nick Coghlan wrote:
> PEP 394 [1] aims to document our collective recommendation for
> allowing shebang lines to specifically request some version of 2.x,
> without requiring that it be exactly 2.7 (or 2.6, etc).
>
> I'd let this drift for a while, but the immi
Le dimanche 12 février 2012 à 16:52 +0100, "Martin v. Löwis" a écrit :
> > Why hard links? Symlinks are much more introspectable. When looking at
> > a hard link I have no easy way to know it's the same as whatever other
> > file in the same directory.
>
> There actually *is* an easy way, in regul
Hello,
Given the randomization fix will ship disabled, I thought it would be
nice to add a maximum element count argument to urlparse.parse_qs, with
a default value of e.g. 1000 (including in bugfix releases). What do
you think?
Regards
Antoine.
__
On Sun, 12 Feb 2012 21:44:22 +0100
"Martin v. Löwis" wrote:
> > Given the randomization fix will ship disabled, I thought it would be
> > nice to add a maximum element count argument to urlparse.parse_qs, with
> > a default value of e.g. 1000 (including in bugfix releases). What do
> > you think?
On Mon, 13 Feb 2012 00:08:45 +0100
mar...@v.loewis.de wrote:
>
> >> b) of limited use for existing installations which won't use the API.
> >
> > Obviously it won't fix vulnerabilities due to some other API. If you
> > propose other APIs we can also fix them.
>
> No, you are missing my point. I a
On Mon, 13 Feb 2012 00:32:07 +0100
mar...@v.loewis.de wrote:
> >> No, you are missing my point. I assume you proposed (even though you
> >> didn't say so explicitly) that parse_qs gets an opt-in API change to
> >> limit the number of parameters. If that is added, it will have no
> >> effect on any
On Wed, 15 Feb 2012 08:39:45 -0800
Guido van Rossum wrote:
>
> What purpose is there to recording timestamps in nanoseconds? For
> clocks that start when the process starts running, float *is*
> (basically) good enough. For measuring e.g. file access times, there
> is no way that the actual time
On Wed, 15 Feb 2012 18:23:55 +0100
Victor Stinner wrote:
>
> Linux supports nanosecond timestamps since Linux 2.6, Windows supports
> 100 ns resolution since Windows 2000 or maybe before. It doesn't mean
> that Windows system clock is accurate: in practical, it's hard to get
> something better th
Le mercredi 15 février 2012 à 18:58 +0100, Victor Stinner a écrit :
> It gives me differences smaller than 1000 ns on Ubuntu 11.10 and a
> Intel Core i5 @ 3.33GHz:
>
> $ ./a.out
> 0 s, 781 ns
> $ ./a.out
> 0 s, 785 ns
> $ ./a.out
> 0 s, 798 ns
> $ ./a.out
> 0 s, 818 ns
> $ ./a.out
> 0 s, 270 ns
On Mon, 13 Feb 2012 12:31:38 +
Mark Shannon wrote:
> Note that the json benchmark is unstable and should be ignored.
Can you elaborate? If it's unstable it should be fixed, not ignored :)
Also, there are two different mako results in your message, which one
is the right one?
Thanks
Antoine
On Wed, 15 Feb 2012 20:56:26 +0100
"Martin v. Löwis" wrote:
>
> With the quartz in Victor's machine, a single clock takes 0.3ns, so
> three of them make a nanosecond. As the quartz may not be entirely
> accurate (and also as the CPU frequency may change) you have to measure
> the clock rate again
On Thu, 16 Feb 2012 13:46:18 +0100
Victor Stinner wrote:
>
> Let's try in a ext4 filesystem:
>
> $ ~/prog/python/timestamp/python
> Python 3.3.0a0 (default:35d6cc531800+, Feb 16 2012, 13:32:56)
> >>> import decimal, os, shutil, time
> >>> open("test", "x").close()
> >>> shutil.copy2("test", "tes
Le jeudi 16 février 2012 à 14:20 +0100, Victor Stinner a écrit :
> > If I run your snippet and inspect modification times using `stat`, the
> > difference is much smaller (around 10 ns, not 1 ms):
> >
> > $ stat test | \grep Modify
> > Modify: 2012-02-16 13:51:25.643597139 +0100
> > $ stat test2 |
On Thu, 16 Feb 2012 19:32:24 +0200
Ezio Melotti wrote:
>
> If I'm writing code that imports cElementTree on 3.3+, and I explicitly
> turn on DeprecationWarnings (that would otherwise be silenced) to check
> if I'm doing something wrong, I would like Python to tell me "You don't
> need to impor
On Wed, 08 Feb 2012 19:18:14 +
Mark Shannon wrote:
> Proposed PEP for new dictionary implementation, PEP 410?
> is attached.
>
So, I'm running a few benchmarks using Twisted's test suite
(see https://bitbucket.org/pitrou/t3k/wiki/Home).
At the end of `python -i bin/trial twisted.internet.t
On Fri, 17 Feb 2012 13:10:51 +
Mark Shannon wrote:
> On 16/02/12 20:45, Antoine Pitrou wrote:
> >
> > On Wed, 08 Feb 2012 19:18:14 +
> > Mark Shannon wrote:
> >> Proposed PEP for new dictionary implementation, PEP 410?
> >> is attached.
> &
Hello,
> I am trying to work on Python bugs following the tutorial given in the
> python website.
> I have installed Tortoise svn and visual studio 2010, I cloned a copy
> of cpython as it is advised in the website using, however I am having
> some problem in compiling it using visual studio 2010
Hi,
> +static PyObject *
> +cm_get___dict__(classmethod *cm, void *closure)
> +{
> +Py_INCREF(cm->cm_dict);
> +return cm->cm_dict;
> +}
>>> def f(): pass
...
>>> cm = classmethod(f)
>>> cm.__dict__
Erreur de segmentation
Regards
Antoine.
That's answering to Benjamin's f46deae68e34, by the way.
Regards
Antoine.
On Sun, 19 Feb 2012 13:11:22 +0100
Antoine Pitrou wrote:
>
> Hi,
>
> > +static PyObject *
> > +cm_get___dict__(classmethod *cm, void *closure)
> > +{
> > +Py_INCRE
On Mon, 20 Feb 2012 23:23:13 +1000
Nick Coghlan wrote:
> Does anyone object to me naming myself PEP czar for PEP 3144?
“Tsar is a title used to designate certain European Slavic monarchs or
supreme rulers.”
Is this our official word?
> There's also basic-but-usable module documentation availabl
On Mon, 20 Feb 2012 16:20:15 +0100
Dirkjan Ochtman wrote:
> On Mon, Feb 20, 2012 at 14:23, Nick Coghlan wrote:
> > I don't personally think the module API needs the provisional
> > disclaimer as the core functionality has been tested for years in
> > ipaddr and the API changes in ipaddress are ju
On Mon, 20 Feb 2012 16:31:13 -0500
Terry Reedy wrote:
>
> I am a little puzzled why a constant sequence of pairs is being stored
> as a mapping instead of a tuple (or list) of 2-tuples (which is compiled
> more efficiently). As near as I can tell, 'tests' and similar constructs
> later in the
On Mon, 20 Feb 2012 20:24:16 -0500
"R. David Murray" wrote:
>
> It seems to me that part of the point of the byte/string split (and the
> lack of automatic coercion) is to make the programmer be explicit about
> converting between unicode and bytes. Having these functions, which
> convert betwee
On Tue, 21 Feb 2012 02:44:32 +0100
barry.warsaw wrote:
> + This is intended to provide protection against a denial-of-service caused
> by
> + carefully-chosen inputs that exploit the worst case performance of a dict
> + insertion, O(n^2) complexity. See
> + http://www.ocert.org/advisorie
On Tue, 21 Feb 2012 12:51:08 +1000
Nick Coghlan wrote:
>
> My one concern with the base64 patch is that it doesn't test that
> mixing types triggers TypeError. While this shouldn't require any
> extra code (the error should arise naturally from the method
> implementation), it should still be tes
Hello,
Shouldn't it be enabled by default in 3.3?
It's currently disabled.
$ ./python -c "print(hash('aa'))"
12416074593111936
[44297 refs]
$ ./python -c "print(hash('aa'))"
12416074593111936
[44297 refs]
Thanks
Antoine.
___
Python-Dev mailing list
On Tue, 21 Feb 2012 14:58:41 -0500
Benjamin Peterson wrote:
> 2012/2/21 Antoine Pitrou :
> >
> > Hello,
> >
> > Shouldn't it be enabled by default in 3.3?
>
> Should you be able to disable it?
PYTHONHASHSEED=0 should disable it. Do we also need a
On Tue, 21 Feb 2012 12:41:17 +0200
Eli Bendersky wrote:
> On Tue, Feb 21, 2012 at 03:59, Nick Coghlan wrote:
>
> > On Tue, Feb 21, 2012 at 11:39 AM, Eli Bendersky wrote:
> > > So the two choices here are either change the documentation or the C
> > > implementation to actually make Element a cl
On Tue, 21 Feb 2012 22:51:48 +0100
"Martin v. Löwis" wrote:
> Am 21.02.2012 20:59, schrieb Antoine Pitrou:
> > On Tue, 21 Feb 2012 14:58:41 -0500
> > Benjamin Peterson wrote:
> >> 2012/2/21 Antoine Pitrou :
> >>>
> >>> He
On Tue, 21 Feb 2012 21:32:23 -0600
Brian Curtin wrote:
> While some effort has gone on to get the 32-bit build to compile
> without warnings (thanks for that!), 64-bit still has numerous
> warnings. Before I push forward on more of the VS2010 port, I'd like
> to have a clean 2008 build all around
On Wed, 22 Feb 2012 13:58:45 +0100
victor.stinner wrote:
>
> +/* Copy a ASCII or latin1 char* string into a Python Unicode string.
> + Return the length of the input string.
> +
> + WARNING: Don't copy the terminating null character and don't check the
> + maximum character (may write a la
On Wed, 22 Feb 2012 12:59:33 -0500
Barry Warsaw wrote:
> On Feb 22, 2012, at 09:04 PM, Stephen J. Turnbull wrote:
>
> >Brett Cannon writes:
> >
> > > I think that's inviting trouble if you can provide the seed. It leads to a
> > > false sense of security
> >
> >I thought the point of providing t
On Thu, 23 Feb 2012 16:18:19 +0100
brett.cannon wrote:
> def _sanity_check(name, package, level):
> """Verify arguments are "sane"."""
> +if not hasattr(name, 'rpartition'):
> +raise TypeError("module name must be str, not {}".format(type(name)))
Why don't you simply use isinsta
On Fri, 24 Feb 2012 00:49:31 +0100
victor.stinner wrote:
> http://hg.python.org/cpython/rev/f89e2f4cda88
> changeset: 75231:f89e2f4cda88
> user:Victor Stinner
> date:Fri Feb 24 00:37:51 2012 +0100
> summary:
> Issue #13706: Fix format(int, "n") for locale with non-ASCII thousa
Hello,
On Sat, 25 Feb 2012 03:24:27 +1000
Nick Coghlan wrote:
> To allow the PEP 407 authors to focus on making the case for doing
> full CPython releases every 6 months (including language spec
> updates), I've created PEP 413 as a competing proposal.
>
> It leaves the current language version
On Sat, 25 Feb 2012 11:24:47 -0500
"Eric V. Smith" wrote:
> On 2/25/2012 11:18 AM, Zachary Ware wrote:
> > Anyhow; I have to say I like Nick's idea put forth in PEP 413, but I
> > agree that the extra versioning info could get pretty awkward.
> > Therefore, why not just make stdlib upgrades part o
On Fri, 24 Feb 2012 19:23:36 +0100
Georg Brandl wrote:
>
> > I also think the branches and releases management should be even
> > simpler:
> >
> > - 2.7: as today
> > - 3.3: bug fixes + stdlib enhancements
> > - default: language enhancements / ABI-breaking changes
> >
> > Every 6 months, a new
On Sat, 25 Feb 2012 18:21:40 +0100
Georg Brandl wrote:
>
> Yes, but anybody developing for 3.3.1 will have to specify "3.3.1+".
> Which is kind of defeating the point of giving them micro versions
> at all.
>
> Frankly, the longer we are discussing about this, the more I get the
> impression tha
On Sun, 26 Feb 2012 14:27:21 +0100
Stefan Krah wrote:
>
> The underlying problems with memoryview were intricate and required
> a long discussion (issue #10181) that led to a complete rewrite
> of memoryobject.c.
>
>
> We have several options with regard to 2.7 and 3.2:
>
> 1) Won't fix.
Gi
On Sun, 26 Feb 2012 09:02:59 +0100
nick.coghlan wrote:
> +
> +No debugging capability is lost, as the original exception context remains
> +available if needed (for example, if an intervening library has incorrectly
> +suppressed valuable underlying details)::
That's debatable, since you now have
Hi,
On Sat, 25 Feb 2012 20:23:39 +
Armin Ronacher wrote:
>
> I just uploaded PEP 414 which proposes am optional 'u' prefix for string
> literals for Python 3.
>
> You can read the PEP online: http://www.python.org/dev/peps/pep-0414/
I don't understand this sentence:
> The automatic upgra
On Sat, 25 Feb 2012 19:13:26 -0800
Guido van Rossum wrote:
> If this can encourage more projects to support Python 3 (even if it's
> only 3.3 and later) and hence improve adoption of Python 3, I'm all
> for it.
>
> A small quibble: I'd like to see a benchmark of a 'u' function implemented in
> C
On Sun, 26 Feb 2012 19:50:10 +0100
mar...@v.loewis.de wrote:
> >> - The formatting operations described here are obsolete and may go away
> >> in future
> >> - versions of Python. Use the new :ref:`string-formatting` in new code.
> >> + The formatting operations described here are modelled o
On Sun, 26 Feb 2012 14:27:21 +0100
Stefan Krah wrote:
> State of PEP-3118 (memoryview part)
>
> Hello,
>
> In Python 3.3 most issues with the memoryview object have been fixed
> in a recent commit (3f9b3b6f7ff0).
Oh and congrats for doing this, of course.
Regards
Antoine.
__
On Sun, 26 Feb 2012 16:18:54 -0500
Brett Cannon wrote:
> >
> > diff --git a/Lib/test/test_imp.py b/Lib/test/test_imp.py
> > --- a/Lib/test/test_imp.py
> > +++ b/Lib/test/test_imp.py
> > @@ -325,6 +325,7 @@
> > self.addCleanup(cleanup)
> > # Touch the __init__.py file.
> > s
On Mon, 27 Feb 2012 11:40:08 +0100
Éric Araujo wrote:
>
> In PEP 386, the rule that versions using an 'rc' marker should sort
> after 'c' is buggy: I don’t think anyone will disagree that 1.0rc1 ==
> 1.0c1 and 1.0rc1 < 1.0c2. The 'rc' marker was added by Tarek shortly
> before the PEP was acce
On Sun, 26 Feb 2012 12:42:53 +
Armin Ronacher wrote:
> Hi,
>
> On 2/26/12 12:35 PM, Serhiy Storchaka wrote:
> > Some microbenchmarks:
> >
> > $ python -m timeit -n 1 -r 100 -s "x = 123" "'foobarbaz_%d' % x"
> > 1 loops, best of 100: 1.24 usec per loop
> > $ python -m timeit -n 1 -
On Mon, 27 Feb 2012 13:09:24 -0800
Ethan Furman wrote:
> Martin v. Löwis wrote:
> >>> Eh? The 2.6 version would also be u('that'). That's the whole point
> >>> of the idiom. You'll need a better counter argument than that.
> >> So the idea is to convert the existing 2.6 code to use parenthesis
On Mon, 27 Feb 2012 16:54:51 -0500
Terry Reedy wrote:
> On 2/27/2012 1:17 PM, Guido van Rossum wrote:
>
> >> I just don't understand the pushback here at all. This is such a
> >> nobrainer.
>
> > I agree. Just let's start deprecating it too, so that once Python 2.x
> > compatibility is no longe
On Tue, 28 Feb 2012 10:02:46 +0100
"Martin v. Löwis" wrote:
>
> On the contrary, I'd expect that the build time using 2to3 is
> significantly shorter than the test suite run times, *in particular*
> for large projects. For example, for Django, 2to3 takes less than
> 3 minutes (IIRC), and the test
On Tue, 28 Feb 2012 21:42:54 +1000
Nick Coghlan wrote:
> But the existing approaches require that, in order to be
> forward compatible with Python 3, a program must be made *worse* in
> Python 2 (i.e. harder to read and harder to write correctly for
> someone that hasn't learned Python 3 yet).
Wr
On Tue, 28 Feb 2012 12:45:54 +0100
Victor Stinner wrote:
> > I think you need to elaborate on your use cases further, ...
>
> A frozendict can be used as a member of a set or as a key in a dictionary.
>
> For example, frozendict is indirectly needed when you want to use an
> object as a key of a
On Tue, 28 Feb 2012 12:07:32 +
Mark Shannon wrote:
> Antoine Pitrou wrote:
> > On Tue, 28 Feb 2012 12:45:54 +0100
> > Victor Stinner wrote:
> >>> I think you need to elaborate on your use cases further, ...
> >> A frozendict can be used as a member
Le mardi 28 février 2012 à 22:14 +1000, Nick Coghlan a écrit :
> If you're using separate branches, then your Python 2 code isn't being
> made forward compatible with Python 3. Yes, it avoids making your
> Python 2 code uglier, but it means maintaining two branches in
> parallel until you drop Pyt
On Tue, 28 Feb 2012 13:14:15 +0100
Victor Stinner wrote:
>
> > See also the PEP 351.
>
> I read the PEP and the email explaining why it was rejected.
I think you should write a separate PEP and explain the use cases
clearly.
cheers
Antoine.
___
Py
4301 - 4400 of 4909 matches
Mail list logo
