On 2009-01-29 01:59, Stephen J. Turnbull wrote:
I think there is definitely something to the notion that the 3.x
vs. 3.0.y distinction should signal something, and I personally like
MAL's suggestion that 3.0.x should be marked some sort of beta in
perpetuity, or at least until 3.1 is ready to
Facundo Batista wrote:
Hi!
In the Python Argentina mail list there's already people passing
examples and asking help about Python 3.
For complete snippets:
#!/usr/bin/env python3.0
vs
#!/usr/bin/env python2.6
And for blocks of code
# this for python 3.0
# this is for python 2.6
I know,
2009/1/29 Senthil Kumaran orsent...@gmail.com:
And for blocks of code
# this for python 3.0
# this is for python 2.6
Too much work, ;)
Seriously, most probably people will forgot to add that after the
third example...
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr:
On Tue, Jan 27, 2009, Raymond Hettinger wrote:
It is becoming the norm in 3.x for functions to return iterators,
generators, or views whereever possible.
I had a thought that pprint() ought to be taught to print iterators:
pprint(enumerate(seq))
pprint(map(somefunc, somedata))
Aahz wrote:
On Tue, Jan 27, 2009, Raymond Hettinger wrote:
It is becoming the norm in 3.x for functions to return iterators,
generators, or views whereever possible.
I had a thought that pprint() ought to be taught to print iterators:
pprint(enumerate(seq))
pprint(map(somefunc,
On Thu, Jan 29, 2009, Michael Foord wrote:
Aahz wrote:
On Tue, Jan 27, 2009, Raymond Hettinger wrote:
It is becoming the norm in 3.x for functions to return iterators,
generators, or views whereever possible.
I had a thought that pprint() ought to be taught to print iterators:
On Thu, 29 Jan 2009 at 10:50, Facundo Batista wrote:
This introduces the problem that some examples are in Py2 and others
are in Py3. Sometimes this is not explicit, and gets confusing. I'm
trying to avoid this confusion when preparing my own examples. So far,
I use (py3) as a prefix for any
On Thu, Jan 29, 2009 at 08:06:18AM -0800, Aahz wrote:
On Thu, Jan 29, 2009, Michael Foord wrote:
Don't we have a pretty-print API - and isn't it spelled __str__ ?
In theory, yes. In practice, we wouldn't be having this discussion if
that really worked. But it probably would make sense to
I'm currently working on a patch that adds the __thiscall calling
convention to ctypes. This calling convention is used on Windows
for calling member functions from C++ classes. The idea is to eventually
allow ctypes to wrap C++ classes.
To test this functionality it is required to add some C++
On Thu, Jan 29, 2009 at 10:27 AM, Thomas Heller thel...@ctypes.org wrote:
Is it appropriate to add C++ source files to the Python repository,
or would that create too much trouble on some platforms?
I don't see a problem with that as long as platforms without C++
compilers aren't affected in
2009/1/29 Oleg Broytmann p...@phd.pp.ru:
On Thu, Jan 29, 2009 at 08:06:18AM -0800, Aahz wrote:
On Thu, Jan 29, 2009, Michael Foord wrote:
Don't we have a pretty-print API - and isn't it spelled __str__ ?
In theory, yes. In practice, we wouldn't be having this discussion if
that really
Thomas Heller schrieb:
To test this functionality it is required to add some C++ source code to the
ctypes private test module _ctypes_test.pyd/_ctypes_test.so.
Is it appropriate to add C++ source files to the Python repository,
or would that create too much trouble on some platforms?
How
Thomas Heller theller at ctypes.org writes:
To test this functionality it is required to add some C++ source code to the
ctypes private test module _ctypes_test.pyd/_ctypes_test.so.
Perhaps you should create a separate test module (_ctypes_pp_test?) so that
platforms without a properly
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 29, 2009, at 6:31 AM, A.M. Kuchling wrote:
If we intend for 3.0 to be a 'beta release', or to weaken the 'no
features in micro releases' rule, then fine; but we have to be *really
clear about it*. Are we? (The 3.0 release page calls it
On Thu, Jan 29, 2009 at 11:50 AM, Antoine Pitrou solip...@pitrou.net wrote:
..
(I also suppose configure can detect the presence of a C++ compiler...)
This test is already there:
$ ./configure
...
checking for g++... g++
configure: WARNING:
By default, distutils will build C++ extension
Ben North wrote:
I find 'functools.partial' useful, but occasionally I'm unable to use it
because it lacks a 'from the right' version. ...
Would there be any interest in this?
I think so. Post your patch to the tracker. Even if eventually
rejected, it will be there for people to use.
Hello,
Ben North ben at redfrontdoor.org writes:
I find 'functools.partial' useful, but occasionally I'm unable to use it
because it lacks a 'from the right' version. E.g., to create a function
which splits a string on commas, you can't say
# Won't work when called:
split_comma =
On Jan 29, 2009, at 6:31 AM, A.M. Kuchling wrote:
If we intend for 3.0 to be a 'beta release', or to weaken the 'no
features in micro releases' rule, then fine; but we have to be *really
clear about it*. Are we? (The 3.0 release page calls it
production-ready.)
On Thu, Jan 29, 2009 at 8:59
On Thu, Jan 29, 2009 at 02:38, Dr Andrew Perella a...@eutechnyx.com wrote:
Hi,
I was thinking of adding a breakpoint opcode to python to enable less
invasive debugging.
I came across posts from 1999 by Vladimir Marangozov and Christian Tismer
discussing this issue but the links to the code
Guido van Rossum wrote:
[...]
Finally, to those who claim that 2.6 is a mess because multiprocessing
wasn't perfectly stable at introduction: that's never been the
standard we've used for totally *new* features. It's always been okay
to add slightly immature features at a major release, as
On Thu, Jan 29, 2009 at 10:57 AM, Steve Holden st...@holdenweb.com wrote:
Guido van Rossum wrote:
[...]
Finally, to those who claim that 2.6 is a mess because multiprocessing
wasn't perfectly stable at introduction: that's never been the
standard we've used for totally *new* features. It's
I think it sets bad precedence to downgrade our confidence in the
release. Again, my position is that it's better to stick to the same
development processes we've always used, fix the most egregious problems
in 3.0.1 with no API changes, but spend most of our energy on a 3.1
release in 6
Is it appropriate to add C++ source files to the Python repository,
or would that create too much trouble on some platforms?
I think there will be massive portability problems, which only fade
after one or two years, until this actually works everywhere.
So failure of this to work shouldn't
Antoine Pitrou wrote:
...
In py3k, we could also use ... (the Ellipsis object) to denote
places where an argument is missing, so that:
split_comma = partial(str.split, ..., ',')
would do what you want.
Thus preventing any use of partial when an argument could be an
the Ellipsis instance.
Scott David Daniels Scott.Daniels at Acm.Org writes:
Antoine Pitrou wrote:
...
In py3k, we could also use ... (the Ellipsis object) to denote
places where an argument is missing, so that:
split_comma = partial(str.split, ..., ',')
would do what you want.
Thus preventing any
Hi all,
Over on the matplotlib mailing list, we ran into a problem with trying
to use Universal newlines with gzip. In virtually all of my code that
reads text files, I use the 'U' flag to open files, it really helps not
having to deal with newline issues. Yes, they are fewer now that the
This discussion probably belongs to python-ideas, but since we already
have this thread, I'll reply here instead of opening a new thread
there.
Ellipsis was introduced into python to serve needs of the numeric
python community. If you think of numpy multiarrays as functions
taking ndim number of
From: Guido van Rossum gu...@python.org
On the one hand I understand that those folks want a stable target. On
the other hand I think they would prefer to find out sooner rather
than later they're using stuff they shouldn't be using any more. It's
a delicate balance for sure, and I certainly
Raymond Hettinger wrote:
From: Guido van Rossum gu...@python.org
On the one hand I understand that those folks want a stable target. On
the other hand I think they would prefer to find out sooner rather
than later they're using stuff they shouldn't be using any more. It's
a delicate balance for
Michael Foord wrote:
Don't we have a pretty-print API - and isn't it spelled __str__ ?
For the reiterable cases like dictionary views (where the object is
not consumed), an appropriate __str__ or __repr__ should be written).
Whether that is something as simple as repr of underlying
dict.items()
On Thu, Jan 29, 2009 at 9:12 AM, Ben North b...@redfrontdoor.org wrote:
I find 'functools.partial' useful, but occasionally I'm unable to use it
because it lacks a 'from the right' version. E.g., to create a function
which splits a string on commas, you can't say
First of all, many functions
Alexander Belopolsky alexander.belopolsky at gmail.com writes:
By this analogy, partial(f, ..., *args) is right_partial with '...'
standing for any number of missing arguments. I you want to specify
exactly one missing argument, you would want to write partial(f, :,
*args), which is not a
On Wed, Jan 28, 2009, M.-A. Lemburg wrote:
Why don't we just mark 3.0.x as experimental branch and keep updating/
fixing things that were not sorted out for the 3.0.0 release ?! I
think that's a fair approach, given that the only way to get field
testing for new open-source software is to
Benjamin Peterson wrote:
On Wed, Jan 28, 2009 at 10:37 PM, brett. cannon
python-check...@python.org wrote:
Author: brett.cannon
Date: Thu Jan 29 05:37:06 2009
New Revision: 69093
Log:
Backport r69092 by hand since svnmerge keeps saying there is a conflict on
'.'.
Just do svn resolved
Leif Walsh wrote:
That said, it seems to me that if we're going to add to
functools.partial, we should go all the way and allow keyword
arguments (or a dict of them, if it's otherwise too hard to
implement). Otherwise, in another few {days, weeks, months} we'll see
another thread like this
Nick Coghlan ncoghlan at gmail.com writes:
If partial starts messing about looking for missing arguments and then
slotting them in, then it is likely to slow down to the point where you
would be better off skipping it and writing a dedicated function that
adds the extra arguments.
Looking
Michael Foord wrote:
Don't we have a pretty-print API - and isn't it spelled __str__ ?
Not really. If it were as simple as calling str(obj), there would be no
need for the pprint module. In any case, it seems that the pprint module
actually calls repr() on objects other than dicts, tuples
On Thu, Jan 29, 2009 at 12:39, Christopher Barker chris.bar...@noaa.gov wrote:
Hi all,
Over on the matplotlib mailing list, we ran into a problem with trying to
use Universal newlines with gzip. In virtually all of my code that reads
text files, I use the 'U' flag to open files, it really
In the past couple of days, test_distutils started failing.
It looks like a pure python error and may have been
introduced by guilherme.polo's checkins:
File c:\py27\lib\distutils\tests\test_sdist.py, line 119, in test_make_distr
ibution
spawn('tar --help')
File
On Fri, Jan 30, 2009 at 12:00 AM, Raymond Hettinger pyt...@rcn.com wrote:
In the past couple of days, test_distutils started failing. It looks like a
pure python error and may have been introduced by guilherme.polo's checkins:
That's me. I'll fix this problem right now.
File
On Thu, Jan 29, 2009 at 9:00 PM, Raymond Hettinger pyt...@rcn.com wrote:
In the past couple of days, test_distutils started failing. It looks like a
pure python error and may have been introduced by guilherme.polo's checkins:
File c:\py27\lib\distutils\tests\test_sdist.py, line 119, in
On 2009-01-29 08:20, Aahz wrote:
The reason I'm chiming in is that I would welcome a PEP that created a
__pprint__ method as an alternative to special-casing. I think that it
would be generically useful for user-created objects, plus once you've
added this feature other people can easily do
[Tarek Ziadé]
That's me. I'll fix this problem right now.
Thanks. I appreciate it.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Thu, Jan 29, 2009 at 4:04 PM, Antoine Pitrou solip...@pitrou.net wrote:
Alexander Belopolsky alexander.belopolsky at gmail.com writes:
By this analogy, partial(f, ..., *args) is right_partial with '...'
standing for any number of missing arguments. I you want to specify
exactly one
On 29-Jan-09, at 3:21 PM, Daniel Stutzbach wrote:
On Thu, Jan 29, 2009 at 4:04 PM, Antoine Pitrou
solip...@pitrou.net wrote:
Alexander Belopolsky alexander.belopolsky at gmail.com writes:
By this analogy, partial(f, ..., *args) is right_partial with '...'
standing for any number of missing
[Aahz]
At the same time, I think each individual
change that doesn't clearly fall into the PEP6 process of being a bugfix
needs to be vetted beyond what's permitted for not-yet-released versions.
To get the ball rolling, I have a candidate for discussion.
Very late in the 3.0 process (after
On Thu, Jan 29, 2009 at 6:12 AM, Ben North b...@redfrontdoor.org wrote:
Hi,
I find 'functools.partial' useful, but occasionally I'm unable to use it
because it lacks a 'from the right' version. E.g., to create a function
which splits a string on commas, you can't say
# Won't work when
On Thu, Jan 29, 2009 at 5:24 PM, Mike Klaas mike.kl...@gmail.com wrote:
And yet, python isn't confined to mathematical notation. *, ** are both
overloaded for use in argument lists to no-one's peril, AFAICT.
Certainly, but there is no danger of confusion them for multiplication in
context,
Mike Klaas wrote:
On 29-Jan-09, at 3:21 PM, Daniel Stutzbach wrote:
[...]
The meaning which numpy attributes to Ellipsis is also the meaning
that mathematical notation has attached to Ellipsis for a very long
time.
And yet, python isn't confined to mathematical notation. *, ** are both
On Thu, Jan 29, 2009 at 3:27 PM, Raymond Hettinger pyt...@rcn.com wrote:
To get the ball rolling, I have a candidate for discussion.
Very late in the 3.0 process (after feature freeze), the bsddb code was
ripped out (good riddance). This had the unfortunate side-effect of
crippling shelves
On the one hand, it is an API change or new feature because people can
(if they choose) access the dbm directly. OTOH, it is basically a
performance fix for shelves whose API won't change at all. The part that is
visible
and incompatible is that 3.0.1 shelves won't be readable by 3.0.0.
A couple additional thoughts FWIW:
* whichdb() selects from multiple file formats, so 3.0.1 would still
be able to read 3.0.0 files. It is the 2.x shelves that won't be
readable at all under any scenario.
* If you're thinking that shelves have very few users and that
3.0.0 has had few
Raymond Hettinger python at rcn.com writes:
* If you're thinking that shelves have very few users and that
3.0.0 has had few adopters, doesn't that mitigate the effects
of making a better format available in 3.0.1? Wouldn't this
be the time to do it?
There was already another
Along the lines of what others have said: pprint() cannot consume an
unknown iterator.
Perhaps so. It's nice to have printing be free of side-effects (other than
the actual printing).
I've been working with 3.0 daily for several months (on a book project)
and mostly think it's great. But
Raymond Hettinger python at rcn.com writes:
P.S. My other experience with 3.0 is that my most frequent error has
changed. It used to be that the number reason for my getting a syntax
error was leaving-off a colon. Now, my number one reason is
omitting parens in a print() function call. I
Raymond Hettinger writes:
My preference is to *not* mark it as experimental.
Don't take the word experimental too seriously. It's clearly an
exaggeration given the current state of 3.0.x. What is meant is an
explicit announcement that the stability rules chosen in response to
the
There are potential problems with doing it that way [1]. The safer
option is to do:
svn revert .
svnmerge merge -M -F py3k-rev
I still don't see the potential problem. If you do svnmerge, svn commit,
all is fine, right? The problem *only* arises if you do svnmerge,
svn up, svn commit - and
On Fri, Jan 30, 2009, Antoine Pitrou wrote:
Raymond Hettinger python at rcn.com writes:
* If you're thinking that shelves have very few users and that
3.0.0 has had few adopters, doesn't that mitigate the effects
of making a better format available in 3.0.1? Wouldn't this
be the time
Don't take the word experimental too seriously. It's clearly an
exaggeration given the current state of 3.0.x. What is meant is an
explicit announcement that the stability rules chosen in response to
the bool-True-False brouhaha will be relaxed for the 3.0.x series
*only*.
The name for
On Thu, Jan 29, 2009 at 18:27, Martin v. Löwis mar...@v.loewis.de wrote:
There are potential problems with doing it that way [1]. The safer
option is to do:
svn revert .
svnmerge merge -M -F py3k-rev
I still don't see the potential problem. If you do svnmerge, svn commit,
all is fine,
Brett Cannon wrote:
On Thu, Jan 29, 2009 at 18:27, Martin v. Löwis mar...@v.loewis.de wrote:
There are potential problems with doing it that way [1]. The safer
option is to do:
svn revert .
svnmerge merge -M -F py3k-rev
I still don't see the potential problem. If you do svnmerge, svn
On Thu, Jan 29, 2009 at 19:03, Martin v. Löwis mar...@v.loewis.de wrote:
Brett Cannon wrote:
On Thu, Jan 29, 2009 at 18:27, Martin v. Löwis mar...@v.loewis.de wrote:
There are potential problems with doing it that way [1]. The safer
option is to do:
svn revert .
svnmerge merge -M -F
svn up
svnmerge
... conflicts
svn revert -R .
svn up
svnmerge
... same conflicts
Ah. In the 3.0 branch, always do svn revert . after svnmerge.
It's ok (Nick says it isn't exactly ok, but I don't understand why)
Martin
___
Python-Dev mailing list
This is my attempt to summarize what everyone has been saying so we
can get this resolved.
From what I can tell, most people like the idea of doing a 3.0.1
release ASAP (like in a week or so fast) with the stuff that should
have been removed from 3.0.0 in the first place removed.
People also
Martin v. Löwis writes:
Don't take the word experimental too seriously. What is meant
is an explicit announcement that the stability rules will be
relaxed for the 3.0.x series *only*.
The name for that shouldn't be experimental, though. I don't think
it needs any name at all.
On Thu, Jan 29, 2009 at 4:58 PM, Raymond Hettinger pyt...@rcn.com wrote:
A couple additional thoughts FWIW:
* whichdb() selects from multiple file formats, so 3.0.1 would still
be able to read 3.0.0 files. It is the 2.x shelves that won't be
readable at all under any scenario.
* If
[Guido van Rossum]
Sorry, not convinced.
No worries. Py3.1 is not far off.
Just so I'm clear. Are you thinking that 3.0.x will never have
fast shelves, or are you thinking 3.0.2 or 3.0.3 after some
external deployment and battle-testing for the module?
Raymond
Ron Adam wrote:
Steven D'Aprano wrote:
Michael Foord wrote:
Don't we have a pretty-print API - and isn't it spelled __str__ ?
Not really. If it were as simple as calling str(obj), there would be
no need for the pprint module.
I agree. And when I want to use pprint, there are usually
Brett Cannon wrote:
This is my attempt to summarize what everyone has been saying so we
can get this resolved.
From what I can tell, most people like the idea of doing a 3.0.1
release ASAP (like in a week or so fast) with the stuff that should
have been removed from 3.0.0 in the first place
On Thu, Jan 29, 2009 at 2:38 AM, Dr Andrew Perella a...@eutechnyx.com wrote:
Hi,
I was thinking of adding a breakpoint opcode to python to enable less
invasive debugging.
I came across posts from 1999 by Vladimir Marangozov and Christian Tismer
discussing this issue but the links to the
1. Barry, who is the release manager for 3.0.1, does not like the idea
of the cruft that is being proposed removed from 3.0.1.
I don't think he actually said that (in fact, I think he said the
opposite). It would be good if he clarified, though.
Regards,
Martin
Just so I'm clear. Are you thinking that 3.0.x will never have
fast shelves
As Guido said, shelves are *already* fast in 3.0, if you are
using the right operating system.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
Terry Reedy wrote:
Ron Adam wrote:
Steven D'Aprano wrote:
Michael Foord wrote:
Don't we have a pretty-print API - and isn't it spelled __str__ ?
Not really. If it were as simple as calling str(obj), there would be
no need for the pprint module.
I agree. And when I want to use pprint,
73 matches
Mail list logo
