Someone asked for the input of "ordinary users" (i.e. non developers) which,
unfortunately, most of the people on this list don't fall in. My experience
with setuptools is that it's poorly documented and assumes a level of
sophistication that isn't always there. While this is fine in a lot of
arena
I didn't see Tav actually say this but are we all agreed that compile()
should be removed from __builtins__?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/
> Not that I'm expecting to be working on PEPs any time soon, but just as a
> different perspective, I would find the effort to open up Google docs to
> be a much higher barrier to doing some editing tweaks than the dvcs case.
> For the DVCS, I'd just write a little script that would (1) update (2)
I'm glad someone sent this out... I was having this EXACT problem today
I've got it installed on my wife's computer and I'm certain that it worked
when I first installed 3.0a but it stopped working (I didn't update Python
but my wife has done several Vista security updates)... Hopefully, that will
I was thinking that the user could just define the delimiter character due
to the differences amongst delimiters used in OS's... but if that isn't a
problem (Skip seemed to think it wouldn't be) then my solution is
functionally identical to the first one he proposed
I think Nick's solution is "Don't let the best be the enemy of the good"
Had this been caught before 3.0 release it might be a different solution
Let's just add a new function that works "correctly"
Martin, it seems to me that a path. method shouldn't require me to pass path
components but inste
never mind about the limit... I was thinking SQL Express
On Thu, Sep 4, 2008 at 1:07 PM, Jeff Hall <[EMAIL PROTECTED]> wrote:
> Doesn't SQLlite still have a 4gb cap?
>
> I'd personally prefer an open source solution (if that's Berkeley so be it
> but there&#x
Doesn't SQLlite still have a 4gb cap?
I'd personally prefer an open source solution (if that's Berkeley so be it
but there's plenty out there... MySQL for one)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
I'm not sure about the first but as for the __reversed__ we had a discussion
yesterday and it was indeed added in 2.4 (oddly, my 2.5 documentation has
this correct... )
--
Haikus are easy
Most make very little sense
Refrigerator
___
Python-Dev mailing li
I realized after I fired off my response that this was still bugging me...
it appears that the documentation is incorrect
from 2.1 Built-in Functions (v2.5 in case it matters... a quick search of
bugs doesn't seem to show anything though)
*reversed*( seq) Return a reverse iterator. seq must be a
Unless I'm misconstruing something the problem is that reversed returns two
different object types depending on if it's a list or a tuple
>>> l = [1,2,3,4]
>>> i = iter(l)
>>> ri = reversed(l)
>>> l
[1, 2, 3, 4]
>>> ri
>>> i
>>> t = (1,2,3,4)
>>> it = iter(t)
>>> rit = reversed(t)
>>> it
>>> ri
>
>
> quote_from_bytes = quote
>>
>
> So either name can be used on either input type, with the idea being that
> you should use quote on a str, and quote_from_bytes on a bytes. Is this a
> good idea or should it be rewritten so each function permits only one input
> type?
>
>
so you can use quote_
>
>
> (Aside: I dislike functions that have a different return type based on
> the value of a parameter.)
>
>
I wanted to stay out of the whole discussion as it's largely over my head...
But I did want to express support for this idea which I think almost rises
to the level of a standard... I see m
oops... baby jumped in my lap... i pretty much said it all though... I think
the error of the software functioning incorrectly may necessitate the
patch... I certainly understand Guido's concern, however.
___
Python-Dev mailing list
Python-Dev@python.org
That's all fine and good but in this case there may be "stealth errors". If
the user/programmer is expecting the first value to hold but instead
On Fri, Jun 27, 2008 at 7:03 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 27, 2008 at 2:54 PM, Fred Drake <[EMAIL PROTECTED]> wrote:
>
To me (and I'm an outsider not a direct developer), it's Python developers
responsibility to handle the Python problems and the Python build bots. The
community build bots are the responsibility of their authors. If JP is
handling the Twisted one then great. It's got a gatekeeper. If no one is
hand
On Wed, Jun 25, 2008 at 4:55 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:
> > It seems to me that the root problem is allocation spikes of legitimate,
> > useful data. Perhaps then we need some sort of "test" to determine if
> > those are legitimate. Perhaps checking every nth (with n decreasi
It seems to me that the root problem is allocation spikes of legitimate,
useful data. Perhaps then we need some sort of "test" to determine if those
are legitimate. Perhaps checking every nth (with n decreasing as allocation
bytes increases) object allocated during a "spike" could be useful. Then
d
I think a better "stump the guido" would be to just have people write the
most convoluted things for simple processes and see how minimalist he could
make the final code... I think we could have some fun with this ;)
___
Python-Dev mailing list
Python-Dev
+1
For what it's worth from a newbie
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
20 matches
Mail list logo
