On 1 nov 2005, at 22.40, Guido van Rossum wrote:
>> [Greg Ewing]
>>> Maybe ** should be defined for functions so that you
>>> could do things like
>>>
>>>up3levels = dirname ** 3
>
> [Raymond Hettinger]
>> Hmm, using the function's own namespace is an interesting idea. It
>> might also be a go
> [Greg Ewing]
> > Maybe ** should be defined for functions so that you
> > could do things like
> >
> >up3levels = dirname ** 3
[Raymond Hettinger]
> Hmm, using the function's own namespace is an interesting idea. It
> might also be a good place to put other functionals:
>
>results = f.m
On 11/1/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
...
>
> I still consider it dead.
>"If the implementation is hard to explain, it's a bad idea."
It is sometimes true, but not always. It may mean two other things:
1. The one trying to explain is not talented enough.
2. The implementation i
"Delaney, Timothy (Tim)" <[EMAIL PROTECTED]> wrote:
>
> Reinhold Birkenfeld wrote:
>
> > And we have solved the "map, filter and reduce are going away! Let's
> > all weep together" problem with one strike!
>
> I'm not sure if you're wildly enthusiastic, or very sarcastic.
>
> I'm not sure whic
On 11/1/05, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> Noam,
>
> There's a simple solution to all this - write a competing PEP. One of
> the two competing PEPs may be accepted.
I will. It may take some time, though.
>
> FWIW, I'm +1 on PEP 351 in general, and -1 on what you've proposed.
>
Guido van Rossum wrote:
> On 11/1/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>
>>At 10:22 AM 11/1/2005 -0700, Guido van Rossum wrote:
>>
>>>* PEP 328 - absolute/relative import
>>
>>I assume that references to 2.4 in that PEP should be changed to 2.5, and
>>so on.
>
>
> For the part that hasn
Reinhold Birkenfeld wrote:
> And we have solved the "map, filter and reduce are going away! Let's
> all weep together" problem with one strike!
I'm not sure if you're wildly enthusiastic, or very sarcastic.
I'm not sure which I should be either ...
The thought does appeal to me - especially fun
> That's fine. I wish that you read my answer, think about it a little,
> and just tell me in a yes or a no if you still consider it dead. I
> think that I have answered all your questions, and I hope that at
> least others would be convinced by them, and that at the end my
> suggestion would be ac
Noam,
There's a simple solution to all this - write a competing PEP. One of
the two competing PEPs may be accepted.
FWIW, I'm +1 on PEP 351 in general, and -1 on what you've proposed.
PEP 351 is simple to explain, simple to implement and leaves things
under the control of the developer. I think
amk> Every PyCon has featured a python-dev sprint. For the past few
amk> years, hacking on the AST branch has been a tradition, but we'll
amk> have to come up with something new for this year's conference...
This is just a comment from the peanut gallery, as it's highly unlikely I'll
Reinhold Birkenfeld wrote:
> Raymond Hettinger wrote:
>
>>[Martin Blais]
>>
I'm always--literally every time-- looking for a more functional
>>
>>form,
>>
something that would be like this:
# apply dirname() 3 times on its results, initializing with p
... = repapply(dirn
On 11/1/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
> > Hmm, using the function's own namespace is an interesting idea. It
> > might also be a good place to put other functionals:
> >
> >results = f.map(data)
> >newf = f.partial(somearg)
>
> And we have solved the "map, filter and r
On 11/1/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
...
>
> I am an advocate for PEP 351. However, I am against your proposed
> implementation/variant of PEP 351 because I don't believe it ads enough
> to warrant the additional complication and overhead necessary for every
> object (even tuples
Raymond Hettinger wrote:
> [Martin Blais]
>> > I'm always--literally every time-- looking for a more functional
> form,
>> > something that would be like this:
>> >
>> ># apply dirname() 3 times on its results, initializing with p
>> >... = repapply(dirname, 3, p)
>
> [Greg Ewing]
>> Maybe
On 11/1/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:35 AM 11/1/2005 -0500, A.M. Kuchling wrote:
> >Every PyCon has featured a python-dev sprint. For the past few years,
> >hacking on the AST branch has been a tradition, but we'll have to come
> >up with something new for this year's conf
On Sun, 2005-10-30 at 19:08 -0600, [EMAIL PROTECTED] wrote:
> Martin> The natural question then is: what operating system, what
> Martin> subversion version are you using?
>
> Sorry, wasn't thinking in terms of svn bugs. I was anticipating some sort
> of obvious pilot error. I am on Mac
[Martin Blais]
> > I'm always--literally every time-- looking for a more functional
form,
> > something that would be like this:
> >
> ># apply dirname() 3 times on its results, initializing with p
> >... = repapply(dirname, 3, p)
[Greg Ewing]
> Maybe ** should be defined for functions so
On 11/1/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 11:14 AM 11/1/2005 -0700, Guido van Rossum wrote:
> >I guess this ought to be recorded. :-(
> >
> >The issue has been beaten to death and my position remains firm:
> >rather than playing namespace games, consistent renaming is the right
> >
At 10:34 AM 11/1/2005 -0800, Neal Norwitz wrote:
>Why can't you add your version's directory to sys.path before importing
>pyexpat?
With library code that can be imported in any order, there is no such thing
as "before". Anyway, Guido has pronounced on this already, so it's moot.
_
Noam Raphael <[EMAIL PROTECTED]> wrote:
> On 10/31/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > > About the users-changing-my-internal-data issue:
> ...
> > You can have a printout before it dies:
> > "I'm crashing your program because something attempted to modify a data
> > structure (here
On 11/1/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 11:14 AM 11/1/2005 -0700, Guido van Rossum wrote:
> >I guess this ought to be recorded. :-(
> >
> >The issue has been beaten to death and my position remains firm:
> >rather than playing namespace games, consistent renaming is the right
> >
At 11:14 AM 11/1/2005 -0700, Guido van Rossum wrote:
>I guess this ought to be recorded. :-(
>
>The issue has been beaten to death and my position remains firm:
>rather than playing namespace games, consistent renaming is the right
>thing to do here. This becomes a trivial source edit,
Well, it's
On 11/1/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 10:22 AM 11/1/2005 -0700, Guido van Rossum wrote:
> >* PEP 328 - absolute/relative import
>
> I assume that references to 2.4 in that PEP should be changed to 2.5, and
> so on.
For the part that hasn't been implemented yet, yes.
> It also
At 10:22 AM 11/1/2005 -0700, Guido van Rossum wrote:
>* PEP 328 - absolute/relative import
I assume that references to 2.4 in that PEP should be changed to 2.5, and
so on.
It also appears to me that the PEP doesn't record the issue brought up by
some people about the current absolute/relative a
On 11/1/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 11/1/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 09:35 AM 11/1/2005 -0500, A.M. Kuchling wrote:
> > >Every PyCon has featured a python-dev sprint. For the past few years,
> > >hacking on the AST branch has been a tradition, but
On 11/1/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:35 AM 11/1/2005 -0500, A.M. Kuchling wrote:
> >Every PyCon has featured a python-dev sprint. For the past few years,
> >hacking on the AST branch has been a tradition, but we'll have to come
> >up with something new for this year's conf
At 09:35 AM 11/1/2005 -0500, A.M. Kuchling wrote:
>Every PyCon has featured a python-dev sprint. For the past few years,
>hacking on the AST branch has been a tradition, but we'll have to come
>up with something new for this year's conference (in Dallas Texas;
>sprints will be Monday Feb. 27 throu
Christoph Ludwig <[EMAIL PROTECTED]> writes:
> Hi,
>
> this is to continue a discussion started back in July by a posting by
> Dave Abrahams http://thread.gmane.org/gmane.comp.python.devel/69651>
> regarding the compiler (C vs. C++) used to compile python's main() and to link
> the executable.
>
Every PyCon has featured a python-dev sprint. For the past few years,
hacking on the AST branch has been a tradition, but we'll have to come
up with something new for this year's conference (in Dallas Texas;
sprints will be Monday Feb. 27 through Thursday March 2).
According to Anthony's release
29 matches
Mail list logo
