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
Christoph Ludwig [EMAIL PROTECTED] writes:
Hi,
this is to continue a discussion started back in July by a posting by
Dave Abrahams url: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.
On
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 through
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 conference
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 we'll have
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
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 appears
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 not
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
thing to do
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's the
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.
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
thing to do
[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 that you
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 OSX
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 conference
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 ** should be
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 would
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 reduce are
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(dirname, 3, p)
[Greg Ewing]
Maybe
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
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
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
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
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't been implemented
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 which I should be
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 is
[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.map(data)
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 good place to put
28 matches
Mail list logo
