On Sun, Feb 26, 2012 at 11:54 PM, Antoine Pitrou wrote:
>> + def prepare_subprocess():
>> + # don't create core file
>> + try:
>> + setrlimit(RLIMIT_CORE, (0, 0))
>> + except (ValueError, resource_error):
>> + pass
>
> Really? This sounds quite wrong,
On Mon, Feb 27, 2012 at 11:55 AM, Terry Reedy wrote:
> I presume such a hook would simply remove 'u' prefixes and would run *much*
> faster than 2to3. If such a hook is satisfactory for 3.2, why would it not
> be satisfactory for 3.3?
Because an import hook is still a lot more complicated than "W
Thanks for writing that up. I'd be amenable if the PEP was clearly
updated to say that ``raise exc from cause`` would change from being
syntactic sugar for ``_hidden = exc; _hidden.__cause__ = cause; raise
exc`` (as it is now) to ``_hidden = exc; _hidden.__cause__ = cause;
_hidden.__suppress_contex
On Mon, Feb 27, 2012 at 10:44 AM, Larry Hastings wrote:
> On 02/26/2012 03:33 PM, Guido van Rossum wrote:
>>
>> One thing I'd like to see happening regardless is support for
>> new-style formatting in the logging module. It's a little tricky to
>> think how that would work, alas -- should this be
On 2/26/2012 7:46 AM, Armin Ronacher wrote:
I am not enthusiastic about adding duplication that is useless for
writing Python 3 code, but like others, I do want to encourage more
porting of libraries to run with Python 3. I understand that the unicode
transition seems the be the biggest barrie
PEP: 415
Title: Implementing PEP 409 differently
Version: $Revision$
Last-Modified: $Date$
Author: Benjamin Peterson
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 26-Feb-2012
Post-History: 26-Feb-2012
Abstract
PEP 409 allows PEP 3134 exception contexts and cause
Nick Coghlan wrote:
Armin's straw poll was actually about whether or not people used the
future import for division, rather than unicode literals. It is indeed
the same problem
There are differences, though. Personally I'm very glad of the
division import -- it's the only thing that keeps me s
On 02/26/2012 03:33 PM, Guido van Rossum wrote:
One thing I'd like to see happening regardless is support for
new-style formatting in the logging module. It's a little tricky to
think how that would work, alas -- should this be a property of the
logger or of the call?
There already is some supp
On 26/02/2012 23:33, Guido van Rossum wrote:
On Sun, Feb 26, 2012 at 3:14 PM, Terry Reedy wrote:
On 2/26/2012 5:38 PM, Nick Coghlan wrote:
Ah, thanks, I knew there was another term that had a new-style
counterpart: percent formatting vs brace formatting.
Hooray!
Exact parallel and value-neu
On 26Feb2012 15:33, Guido van Rossum wrote:
| One thing I'd like to see happening regardless is support for
| new-style formatting in the logging module. It's a little tricky to
| think how that would work, alas -- should this be a property of the
| logger or of the call?
Surely the call? The cal
On Sun, 2012-02-26 at 23:06 +, Vinay Sajip wrote:
> Chris McDonough plope.com> writes:
>
> > If we use the unicode_literals future import, or some other exernal
> > module strategy, it doesn't help much with the hitnrun contributor
> > thing, I fear.
>
> Surely some curating of hit-and-run c
On Sun, Feb 26, 2012 at 3:14 PM, Terry Reedy wrote:
> On 2/26/2012 5:38 PM, Nick Coghlan wrote:
>>
>> Ah, thanks, I knew there was another term that had a new-style
>> counterpart: percent formatting vs brace formatting.
>
> Hooray!
> Exact parallel and value-neutral.
Can we stop it with the "pol
On 2/26/2012 5:38 PM, Nick Coghlan wrote:
Ah, thanks, I knew there was another term that had a new-style
counterpart: percent formatting vs brace formatting.
Hooray!
Exact parallel and value-neutral.
--
Terry Jan Reedy
___
Python-Dev mailing list
Py
On Feb 26, 2012, at 05:44 PM, Brett Cannon wrote:
>On Sat, Feb 25, 2012 at 22:13, 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.
>>
>>
>+1 from me for the same rea
Chris McDonough plope.com> writes:
> If we use the unicode_literals future import, or some other exernal
> module strategy, it doesn't help much with the hitnrun contributor
> thing, I fear.
Surely some curating of hit-and-run contributions takes place? If you accept
contributions from hit-and-r
On Sat, Feb 25, 2012 at 22:13, 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.
>
>
+1 from me for the same reasons.
If this were to go in then for Python 3.3 the sectio
Ah, thanks, I knew there was another term that had a new-style counterpart:
percent formatting vs brace formatting.
--
Sent from my phone, thus the relative brevity :)
On Feb 27, 2012 7:53 AM, "Georg Brandl" wrote:
> On 02/26/2012 10:13 PM, Nick Coghlan wrote:
>
>> On Mon, Feb 27, 2012 at 5:23 A
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 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 02/26/2012 10:13 PM, Nick Coghlan wrote:
On Mon, Feb 27, 2012 at 5:23 AM, Eli Bendersky wrote:
It would be nice to call it something else than "printf-style
formatting". While it is certainly modelled on printf(), knowledge of C
or printf is not required to understand %-style formatting
Stefan, thank you for the massive rewrite.
On 2/26/2012 11:21 AM, Paul Moore wrote:
On 26 February 2012 13:41, Antoine Pitrou wrote:
We have several options with regard to 2.7 and 3.2:
1) Won't fix.
Given the extent of the rewrite, this one has my preference.
+1 (although I'd word it a
On 27Feb2012 07:13, Nick Coghlan wrote:
| On Mon, Feb 27, 2012 at 5:23 AM, Eli Bendersky wrote:
| >> It would be nice to call it something else than "printf-style
| >> formatting". While it is certainly modelled on printf(), knowledge of C
| >> or printf is not required to understand %-style form
On Sun, 2012-02-26 at 16:06 -0500, Barry Warsaw wrote:
> On Feb 26, 2012, at 09:20 PM, Nick Coghlan wrote:
>
> >It reduces the problem (compared to omitting the import and using a
> >u() function), but it's still ugly and still involves the "action at a
> >distance" of the unicode literals import.
Stefan Krah wrote:
Options 2) and 3) would ideally entail one backwards incompatible
bugfix: In 2.7 and 3.2 assignment to a memoryview with format 'B'
rejects integers but accepts byte objects, but according to the
struct syntax mandated by the PEP it should be the other way round.
Maybe a com
On Sun, Feb 26, 2012 at 12:13, antoine.pitrou wrote:
> http://hg.python.org/cpython/rev/1d7472b015f0
> changeset: 75296:1d7472b015f0
> user:Antoine Pitrou
> date:Sun Feb 26 18:09:50 2012 +0100
> summary:
> Issue #14080: fix sporadic test_imp failure. Patch by Stefan Krah.
>
>
On Mon, Feb 27, 2012 at 5:23 AM, Eli Bendersky wrote:
>
>> It would be nice to call it something else than "printf-style
>> formatting". While it is certainly modelled on printf(), knowledge of C
>> or printf is not required to understand %-style formatting, nor even to
>> appreciate it.
>
>
> +1.
On Feb 26, 2012, at 09:20 PM, Nick Coghlan wrote:
>It reduces the problem (compared to omitting the import and using a
>u() function), but it's still ugly and still involves the "action at a
>distance" of the unicode literals import.
Frankly, that doesn't bother me at all. I've been using the fu
On Mon, Feb 27, 2012 at 5:54 AM, Antoine Pitrou wrote:
> It would be nice to call it something else than "printf-style
> formatting". While it is certainly modelled on printf(), knowledge of C
> or printf is not required to understand %-style formatting, nor even to
> appreciate it.
-1. Calling i
Hi,
On 2/26/12 5:45 PM, Antoine Pitrou wrote:
>> The automatic upgrading of binary strings to unicode strings that
>> would be enabled by this proposal would make it much easier to port
>> such libraries over.
>
> What "automatic upgrading" is that talking about?
The word "upgrade" is probably so
On 2/26/2012 1:50 PM, mar...@v.loewis.de wrote:
Zitat von Eli Bendersky :
- 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 on C's pr
> It would be nice to call it something else than "printf-style
> formatting". While it is certainly modelled on printf(), knowledge of C
> or printf is not required to understand %-style formatting, nor even to
> appreciate it.
>
+1. The section is already titled "old string formatting operations
On 26 Feb 2012, at 17:45, Antoine Pitrou wrote:
>
> 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/pe
On Sun, Feb 26, 2012 at 10:11 AM, Simon Cross
wrote:
> On Sun, Feb 26, 2012 at 6:12 PM, Larry Hastings wrote:
>> It's probably neutral. But I do have one question: can you foresee the
>> scientific community moving to a finer resolution than nanoseconds in our
>> lifetimes?
>
> I think we're alr
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, Feb 26, 2012 at 6:12 PM, Larry Hastings wrote:
> It's probably neutral. But I do have one question: can you foresee the
> scientific community moving to a finer resolution than nanoseconds in our
> lifetimes?
I think we're already there. Even just in radio astronomy new arrays
like ALMA
On 24 February 2012 22:20, wrote:
> I find the .format syntax too complicated and difficult to learn. It has
> so many bells and whistles, making it more than just a *mini* language.
> So for my own code, I always prefer % formatting for simplicity.
>
> +1
> Regards,
> Martin
>
___
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
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
This seems like too strong a statement:
"Python 2.6 and Python 2.7 support syntax features from Python 3 which for
the most part make a unified code base possible. Many thought that the
unicode_literals future import might make a common source possible, but it
turns out that it's d
Also, data collection will almost always be done by specialized hardware
and the data stored off for deferred processing and analysis.
Tony
On Sun, Feb 26, 2012 at 11:34 AM, Tony Koker wrote:
> my 2 cents...
>
> being in electronics for over 30 years, it is forever expanding in both
> direction
my 2 cents...
being in electronics for over 30 years, it is forever expanding in both
directions, bigger mega, giga, tera, peta, etc. AND smaller nano, pico,
femto, atto.
but, I agree that it is moot, as it is not the range, which is usually
expressed in an exponential component of the system bei
On 26 February 2012 13:41, Antoine Pitrou wrote:
>> We have several options with regard to 2.7 and 3.2:
>>
>> 1) Won't fix.
>
> Given the extent of the rewrite, this one has my preference.
+1 (although I'd word it as "fixed in 3.3" rather than "won't fix").
Paul.
__
On 02/26/2012 06:51 AM, Simon Cross wrote:
There are good scientific use cases for nanosecond time resolution
(e.g. radio astronomy) where one is actually measuring time down to
that level and taking into account propagation delays. I have first
hand experience [...]
I'm not sure whether any of
+1 for won't fix.
On Feb 26, 2012 9:46 PM, "Antoine Pitrou" wrote:
> 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.
> >
On Sun, Feb 26, 2012 at 1:31 AM, Guido van Rossum wrote:
> I still think that when you are actually interested in *using* times,
> the current float format is absolutely fine. Anybody who thinks they
> need to accurately know the absolute time that something happened with
> nanosecond accuracy is
On Sun, Feb 26, 2012 at 3:16 PM, Eli Bendersky wrote:
> 7.2.3.1 says, shortly after the first table:
>
> "
>
> Native size and alignment are determined using the C compiler’s sizeof
> expression. This is always combined with native byte order.
>
> Standard size depends only on the format character
> Scratch that, *I* don't agree. timedelta is a pretty clumsy type to
> use. Have you ever tried to compute the number of seconds between two
> datetimes? You can't just use the .seconds field, you have to combine
> the .days and .seconds fields. And negative timedeltas are even harder
> due to the
> Scratch that, *I* don't agree. timedelta is a pretty clumsy type to
> use. Have you ever tried to compute the number of seconds between two
> datetimes? You can't just use the .seconds field, you have to combine
> the .days and .seconds fields. And negative timedeltas are even harder
> due to the
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
Sounds reasonable for me. Thanks!
On Sun, Feb 26, 2012 at 3:16 PM, Eli Bendersky wrote:
>
>
> On Sun, Feb 26, 2012 at 15:09, Paul Moore wrote:
>
>> On 26 February 2012 12:34, Eli Bendersky wrote:
>> > On Sun, Feb 26, 2012 at 12:33, pmon mail wrote:
>> >> Documentation clearly states that the
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
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). Many features have been added, see:
http://docs.python.org/dev/whatsnew/3.3.html
The underlying problems with memoryview were intricate and require
On Sun, Feb 26, 2012 at 15:09, Paul Moore wrote:
> On 26 February 2012 12:34, Eli Bendersky wrote:
> > On Sun, Feb 26, 2012 at 12:33, pmon mail wrote:
> >> Documentation clearly states that the 'L' is a 4 byte integer.
> >>
> >> Is this a bug? I'm I missing something?
> >>
> >
> > By default pa
>
> - 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 on C's printf()
> + syntax. They only support formatting of certain b
On 26 February 2012 12:34, Eli Bendersky wrote:
> On Sun, Feb 26, 2012 at 12:33, pmon mail wrote:
>> Documentation clearly states that the 'L' is a 4 byte integer.
>>
>> Is this a bug? I'm I missing something?
>>
>
> By default pack uses native size, not standard size. On a 64-bit machine:
As th
26.02.12 14:42, Armin Ronacher написав(ла):
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 -r 100 -s "x = 123" "str('foobarbaz_%d') %
Hi,
On 2/26/12 12:42 PM, Vinay Sajip wrote:
> When this came up earlier (when I think Chris McDonough raised it) the issue
> of
> what to do on 3.2 came up, and though it has been addressed somewhat in the
> PEP,
> it would be nice to see the suggested on-installation hook fleshed out a
> littl
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 -r 100 -s "x = 123" "str('foobarbaz_%d') % x"
> 1 loops, best of 100: 1
Hi,
On 2/26/12 12:34 PM, Ned Batchelder wrote:
> There are already __future__ imports that violate this principle: from
> __future__ import division. That doesn't mean I'm in favor of this new
> __future__, just keeping a wide angle on the viewfinder.
That's actually mentioned in the PEP :-)
On Saturday, February 25, 2012 at 10:13 PM, 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
Nick Coghlan gmail.com> writes:
> It reduces the problem (compared to omitting the import and using a
> u() function), but it's still ugly and still involves the "action at a
> distance" of the unicode literals import.
I agree about the action-at-a-distance leading to non-obvious bugs and wasted
On Sun, Feb 26, 2012 at 10:34 PM, Ned Batchelder wrote:
> There are already __future__ imports that violate this principle: from
> __future__ import division. That doesn't mean I'm in favor of this new
> __future__, just keeping a wide angle on the viewfinder.
Armin's straw poll was actually ab
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 -r 100 -s "x = 123" "str('foobarbaz_%d') % x"
1 loops, best of 100: 1.59 usec per loop
$ python -m timeit -n 1 -r 100 -s "x =
On 2/26/2012 6:14 AM, Nick Coghlan wrote:
As soon as you allow the use of "from __future__ import
unicode_literals" or a module level "__metaclass__ = type", you can't
review diffs in isolation any more - whether the diff is correct or
not will depend on the presence or absence of module level tw
On Sun, Feb 26, 2012 at 12:33, pmon mail wrote:
> Hi
>
> I have found myself in the following troubling situation.
>
> I'm running the following code on a Python 2.6.5 on Linux x86:
> Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
> [GCC 4.4.3] on linux2
> Type "help", "copyright", "credits" or
Nick Coghlan gmail.com> writes:
> The PEP already mentions that. In fact, all bar the first paragraph in
> the "Rationale and Goals" section discusses it. However, it's the last
I didn't meaning the __future__ import bit, but a discussion re. alternatives to
u('xxx').
> Future imports work well
Hi
I have found myself in the following troubling situation.
I'm running the following code on a Python 2.6.5 on Linux x86:
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> len(struc
On Sun, Feb 26, 2012 at 9:00 PM, Steven D'Aprano wrote:
> I think your suggestion is not well explained. You suggested a function n,
> expected to take a string literal. The example you gave earlier was:
>
> n('xxx')
>
> But it seems to me that this is a no-op, because 'xxx' is already the native
On Sun, Feb 26, 2012 at 7:05 PM, Vinay Sajip wrote:
> The PEP does not consider an alternative idea such as using "from __future__
> import unicode_literals" in code which needs to run on 2.x, together with
> e.g. a
> callable n('xxx') which can be used where native strings are needed. This
> av
Vinay Sajip wrote:
Serhiy Storchaka gmail.com> writes:
n = str
Well, n to indicate that native string is required.
str indicates the native string type, because it *is* the native string type.
By definition, str = str in both Python 2.x and Python 3.x. There's no point
in aliasing it to
> It probably wouldn't be very difficult to make element_new() the tp_new
> of Element_Type, and expose that type as "Element".
> That would settle the issue nicely and avoid compatibility concerns :)
>
> Regards
>
I guess it's not as simple as that. element_new doesn't quite have the
signature re
Serhiy Storchaka gmail.com> writes:
> n = str
Well, n to indicate that native string is required.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.py
26.02.12 11:05, Vinay Sajip написав(ла):
The PEP does not consider an alternative idea such as using "from __future__
import unicode_literals" in code which needs to run on 2.x, together with e.g. a
callable n('xxx') which can be used where native strings are needed. This avoids
the need to reint
On 02/25/2012 07:04 PM, Guido van Rossum wrote:
As to the changes alluded to in #5: Let os.stat() and friends return
extra fields st_atime_ns [...] We don't need a PEP for
this proposal; we can just open a tracker issue and hash out the
details during the code review.
http://bugs.python.org/is
On 02/25/2012 03:31 PM, Guido van Rossum wrote:
On Sat, Feb 25, 2012 at 1:31 PM, Barry Warsaw wrote:
On Feb 23, 2012, at 01:28 PM, Larry Hastings wrote:
* Change the result of os.stat to be a custom class rather than a
PyStructSequence. Support the sequence protocol on the custom class bu
Big +1
On Feb 26, 2012 4:41 PM, "Eli Bendersky" wrote:
>
> On Sat, Feb 25, 2012 at 12:20, "Martin v. Löwis" wrote:
>
>> > I find that strange, especially for an expert Python dev. I, a newbie,
>> > find it far friendlier (and easier for a new programmer to grasp).
>> > Maybe it's because I use it
The PEP does not consider an alternative idea such as using "from __future__
import unicode_literals" in code which needs to run on 2.x, together with e.g. a
callable n('xxx') which can be used where native strings are needed. This avoids
the need to reintroduce the u'xxx' literal syntax, makes it
> Indeed, that note was written before we decided that getting rid of
> "%" formatting altogether would be a bad idea.
>
> It would be better to update it to say something like:
>
> "The formatting operations described here are modelled on C's printf()
> syntax. They only support formatting of cert
On Sat, Feb 25, 2012 at 12:20, "Martin v. Löwis" wrote:
> > I find that strange, especially for an expert Python dev. I, a newbie,
> > find it far friendlier (and easier for a new programmer to grasp).
> > Maybe it's because I use it all the time, and you don't?
>
> That is most likely the case.
79 matches
Mail list logo
