On Sat, Feb 25, 2012 at 12:20, Martin v. Löwis mar...@v.loewis.de 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
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 certain
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
Big +1
On Feb 26, 2012 4:41 PM, Eli Bendersky eli...@gmail.com wrote:
On Sat, Feb 25, 2012 at 12:20, Martin v. Löwis mar...@v.loewis.dewrote:
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
On 02/25/2012 03:31 PM, Guido van Rossum wrote:
On Sat, Feb 25, 2012 at 1:31 PM, Barry Warsawba...@python.org 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
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.
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
Serhiy Storchaka storchaka at 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:
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 required
Vinay Sajip wrote:
Serhiy Storchaka storchaka at 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
On Sun, Feb 26, 2012 at 7:05 PM, Vinay Sajip vinay_sa...@yahoo.co.uk 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
On Sun, Feb 26, 2012 at 9:00 PM, Steven D'Aprano st...@pearwood.info 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
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
Nick Coghlan ncoghlan at 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
On Sun, Feb 26, 2012 at 12:33, pmon mail pmon.m...@gmail.com 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,
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 tweak
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 = 123
On Sun, Feb 26, 2012 at 10:34 PM, Ned Batchelder n...@nedbatchelder.com 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
Nick Coghlan ncoghlan at 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
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 in
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 :-)
A
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.59 usec per
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
little
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') % x
On 26 February 2012 12:34, Eli Bendersky eli...@gmail.com wrote:
On Sun, Feb 26, 2012 at 12:33, pmon mail pmon.m...@gmail.com 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
- 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
On Sun, Feb 26, 2012 at 15:09, Paul Moore p.f.mo...@gmail.com wrote:
On 26 February 2012 12:34, Eli Bendersky eli...@gmail.com wrote:
On Sun, Feb 26, 2012 at 12:33, pmon mail pmon.m...@gmail.com wrote:
Documentation clearly states that the 'L' is a 4 byte integer.
Is this a bug? I'm I
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
On Sun, 26 Feb 2012 14:27:21 +0100
Stefan Krah ste...@bytereef.org 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)
Sounds reasonable for me. Thanks!
On Sun, Feb 26, 2012 at 3:16 PM, Eli Bendersky eli...@gmail.com wrote:
On Sun, Feb 26, 2012 at 15:09, Paul Moore p.f.mo...@gmail.com wrote:
On 26 February 2012 12:34, Eli Bendersky eli...@gmail.com wrote:
On Sun, Feb 26, 2012 at 12:33, pmon mail
On Sun, 26 Feb 2012 09:02:59 +0100
nick.coghlan python-check...@python.org 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
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, Feb 26, 2012 at 3:16 PM, Eli Bendersky eli...@gmail.com 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
On Sun, Feb 26, 2012 at 1:31 AM, Guido van Rossum gu...@python.org 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
+1 for won't fix.
On Feb 26, 2012 9:46 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 26 Feb 2012 14:27:21 +0100
Stefan Krah ste...@bytereef.org wrote:
The underlying problems with memoryview were intricate and required
a long discussion (issue #10181) that led to a complete
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
On 26 February 2012 13:41, Antoine Pitrou solip...@pitrou.net 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.
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
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 tko...@gmail.com wrote:
my 2 cents...
being in electronics for over 30 years, it is forever expanding in
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
Hi,
On Sat, 25 Feb 2012 20:23:39 +
Armin Ronacher armin.ronac...@active-4.com 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:
On Sat, 25 Feb 2012 19:13:26 -0800
Guido van Rossum gu...@python.org 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
On 24 February 2012 22:20, mar...@v.loewis.de 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 Sun, Feb 26, 2012 at 6:12 PM, Larry Hastings la...@hastings.org 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
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 on C's
On Sun, Feb 26, 2012 at 10:11 AM, Simon Cross
hodgestar+python...@gmail.com wrote:
On Sun, Feb 26, 2012 at 6:12 PM, Larry Hastings la...@hastings.org wrote:
It's probably neutral. But I do have one question: can you foresee the
scientific community moving to a finer resolution than nanoseconds
On 26 Feb 2012, at 17:45, Antoine Pitrou wrote:
Hi,
On Sat, 25 Feb 2012 20:23:39 +
Armin Ronacher armin.ronac...@active-4.com wrote:
I just uploaded PEP 414 which proposes am optional 'u' prefix for string
literals for Python 3.
You can read the PEP online:
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 so if
On 2/26/2012 1:50 PM, mar...@v.loewis.de wrote:
Zitat von Eli Bendersky eli...@gmail.com:
- 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
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 something
On Mon, Feb 27, 2012 at 5:54 AM, Antoine Pitrou solip...@pitrou.net 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.
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 future
On Mon, Feb 27, 2012 at 5:23 AM, Eli Bendersky eli...@gmail.com 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.
On Sun, Feb 26, 2012 at 12:13, antoine.pitrou python-check...@python.orgwrote:
http://hg.python.org/cpython/rev/1d7472b015f0
changeset: 75296:1d7472b015f0
user:Antoine Pitrou solip...@pitrou.net
date:Sun Feb 26 18:09:50 2012 +0100
summary:
Issue #14080: fix sporadic
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
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.
On 27Feb2012 07:13, Nick Coghlan ncogh...@gmail.com wrote:
| On Mon, Feb 27, 2012 at 5:23 AM, Eli Bendersky eli...@gmail.com 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
Stefan, thank you for the massive rewrite.
On 2/26/2012 11:21 AM, Paul Moore wrote:
On 26 February 2012 13:41, Antoine Pitrousolip...@pitrou.net 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
On 02/26/2012 10:13 PM, Nick Coghlan wrote:
On Mon, Feb 27, 2012 at 5:23 AM, Eli Benderskyeli...@gmail.com 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
On Sun, 26 Feb 2012 14:27:21 +0100
Stefan Krah ste...@bytereef.org 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 br...@python.org 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.
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 g.bra...@gmx.net wrote:
On 02/26/2012 10:13 PM, Nick Coghlan wrote:
On Mon, Feb 27,
On Sat, Feb 25, 2012 at 22:13, Guido van Rossum gu...@python.org 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
Chris McDonough chrism at 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
On Feb 26, 2012, at 05:44 PM, Brett Cannon wrote:
On Sat, Feb 25, 2012 at 22:13, Guido van Rossum gu...@python.org 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
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
On Sun, Feb 26, 2012 at 3:14 PM, Terry Reedy tjre...@udel.edu 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
On Sun, 2012-02-26 at 23:06 +, Vinay Sajip wrote:
Chris McDonough chrism at 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
On 26Feb2012 15:33, Guido van Rossum gu...@python.org 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
On 26/02/2012 23:33, Guido van Rossum wrote:
On Sun, Feb 26, 2012 at 3:14 PM, Terry Reedytjre...@udel.edu 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
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
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
PEP: 415
Title: Implementing PEP 409 differently
Version: $Revision$
Last-Modified: $Date$
Author: Benjamin Peterson benja...@python.org
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
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
On Mon, Feb 27, 2012 at 10:44 AM, Larry Hastings la...@hastings.org 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 --
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;
On Mon, Feb 27, 2012 at 11:55 AM, Terry Reedy tjre...@udel.edu 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
On Sun, Feb 26, 2012 at 11:54 PM, Antoine Pitrou solip...@pitrou.net wrote:
+ def prepare_subprocess():
+ # don't create core file
+ try:
+ setrlimit(RLIMIT_CORE, (0, 0))
+ except (ValueError, resource_error):
+ pass
Really? This sounds quite
79 matches
Mail list logo
