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,
> 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
http://mail
> 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
___
On Thu, Jan 29, 2009 at 2:38 AM, Dr Andrew Perella 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 are all ou
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
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 ad
[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
___
On Thu, Jan 29, 2009 at 4:58 PM, Raymond Hettinger 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 you're think
"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 na
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 s
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 additional
output
> 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 mail
On Thu, 29 Jan 2009 at 16:43, Raymond Hettinger wrote:
On Thu, 29 Jan 2009 at 15:40, Guido van Rossum wrote:
Also you could try find shelve users (are there
any?)
I'm a big fan of shelves and have always used them extensively.
Not sure if anyone else cares about them though.
I use them.
On Thu, Jan 29, 2009 at 19:03, "Martin v. Löwis" wrote:
> Brett Cannon wrote:
>> On Thu, Jan 29, 2009 at 18:27, "Martin v. Löwis" wrote:
There are potential problems with doing it that way [1]. The safer
option is to do:
svn revert .
svnmerge merge -M -F
>>> I still don'
Brett Cannon wrote:
> On Thu, Jan 29, 2009 at 18:27, "Martin v. Löwis" wrote:
>>> There are potential problems with doing it that way [1]. The safer
>>> option is to do:
>>>
>>> svn revert .
>>> svnmerge merge -M -F
>> I still don't see the potential problem. If you do svnmerge, svn commit,
>> al
On Thu, Jan 29, 2009 at 18:27, "Martin v. Löwis" wrote:
>> There are potential problems with doing it that way [1]. The safer
>> option is to do:
>>
>> svn revert .
>> svnmerge merge -M -F
>
> I still don't see the potential problem. If you do svnmerge, svn commit,
> all is fine, right? The probl
> 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 f
On Fri, Jan 30, 2009, Antoine Pitrou wrote:
> Raymond Hettinger 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 ti
> There are potential problems with doing it that way [1]. The safer
> option is to do:
>
> svn revert .
> svnmerge merge -M -F
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 clea
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 bool-True
Raymond Hettinger 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 tho
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 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 proposal fo
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 ado
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.
Tha
On Thu, Jan 29, 2009 at 3:27 PM, Raymond Hettinger 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 which now f
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. *, ** a
On Thu, Jan 29, 2009 at 5:24 PM, Mike Klaas 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, whereas:
split_com
On Thu, Jan 29, 2009 at 6:12 AM, Ben North 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 called:
> split
[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 f
On 29-Jan-09, at 3:21 PM, Daniel Stutzbach wrote:
On Thu, Jan 29, 2009 at 4:04 PM, Antoine Pitrou
wrote:
Alexander Belopolsky 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
> exac
On Thu, Jan 29, 2009 at 4:04 PM, Antoine Pitrou wrote:
> Alexander Belopolsky 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 wr
[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:
http://mail.python.org/mailman/options
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 som
On Thu, Jan 29, 2009 at 9:00 PM, Raymond Hettinger 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
> test_make_d
On Fri, Jan 30, 2009 at 12:00 AM, Raymond Hettinger 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 "c:\py27\lib\distutils\t
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 "c:\py27\lib\distutils\s
On Thu, Jan 29, 2009 at 12:39, Christopher Barker 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 helps not having to
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 an
Nick Coghlan 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 for mis
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 th
Benjamin Peterson wrote:
> On Wed, Jan 28, 2009 at 10:37 PM, brett. cannon
> 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 ."
Ther
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
Alexander Belopolsky 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 valid syntax even i
On Thu, Jan 29, 2009 at 9:12 AM, Ben North 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 like this are easy
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 ".items()" for an items view,
Raymond Hettinger wrote:
From: "Guido van Rossum"
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 ce
From: "Guido van Rossum"
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 don't want to open
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
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
Mac
Scott David Daniels 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 us
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
> 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 b
> 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
On Thu, Jan 29, 2009 at 10:57 AM, Steve Holden 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 always been
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,
On Thu, Jan 29, 2009 at 02:38, Dr Andrew Perella 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 are all out
> 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
Hello,
Ben North 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
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.
_
On Thu, Jan 29, 2009 at 11:50 AM, Antoine Pitrou 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 modules with "g++".
-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
prod
Thomas Heller 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 configured C+
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?
H
2009/1/29 Oleg Broytmann :
> 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.
On Thu, Jan 29, 2009 at 10:27 AM, Thomas Heller 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 the build process.
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 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 sens
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 exam
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 itera
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, someda
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))
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 called:
split_comma = partial(str.split, sep = ',')
and to create a 'log to
2009/1/29 Senthil Kumaran :
> 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: http://www.python.org/a
> 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 kn
Hi!
In the Python Argentina mail list there's already people passing
examples and asking help about Python 3.
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 o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Evgeni Golov wrote:
> I'd like to write a small daemon in Python, which should never be
> swapped out (on Linux, this daemon will be Linux specific, so no need
> in a platform-independent solution).
>
> In C I'd do:
> #include
> mlockall(MCL_FUTURE);
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 are all out of date.
Did anything come of this? Is this a good approach to take?
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
79 matches
Mail list logo
