2008/11/24 Ali art <[EMAIL PROTECTED]>:
>
> What did i do wrong?
>
You should ask these kind of questions in the Python general list:
http://www.python.org/mailman/listinfo/python-list
This Python-3000 list is about developing Python 3 *itself*, not
developing *in* Python
Regards,
--
.
2008/11/18 "Martin v. Löwis" <[EMAIL PROTECTED]>:
> While I'm happy that Barry has automated his part to a high degree,
> my part is, unfortunately, much less automated. I could personally
> automate the build process a bit more, but part of it is also testing
> of the installers, which is manual.
2008/11/17 Barry Warsaw <[EMAIL PROTECTED]>:
> Martin suggests, and I agree, that we should release Python 3.0 final and
> 2.6.1 at the same time. Makes sense to me. That would mean that Python
> 2.6.1 should be ready on 03-Dec (well, if Python 3.0 is ready then!).
2.6.1 only two months after 2
2008/10/6 Raymond Hettinger <[EMAIL PROTECTED]>:
>> 15-Oct-2008 3.0 beta 4
>> 05-Nov-2008 3.0 rc 2
>> 19-Nov-2008 3.0 rc 3
>> 03-Dec-2008 3.0 final
>>
>> Given what still needs to be done, is this a reasonable schedule? Do we
>> need two more betas?
>
> Yes to both questions.
I agree with you h
2008/10/4 Brett Cannon <[EMAIL PROTECTED]>:
> So the mailing list is a good idea. Perhaps it should just be
> python-porting so that it can also be used for people who have
> problems with minor releases?
+1. I'd try to help on that list, also.
--
.Facundo
Blog: http://www.taniquetil.com.a
2008/9/4 Raymond Hettinger <[EMAIL PROTECTED]>:
> Can I go ahead with some bug fixes and doc improvements
> or should I wait until after Friday?
Doc improvements: go ahead.
Bug fixes: the patchs should be revised by other developer.
(I'll be hanging around in #python-dev today and tomorrow, btw
Hi!
The issue 600362 has two patches (one for 2.6 and the other for 3.0)
that are ready to commit (with a small change in the docs). This
patches relocates the parse_qs and parse_qsl functions into the
urlparse module (urllib.parse in 3k), bringing them from the cgi one.
For backward compatibilit
Congratulations to Andrew Kuchling for doing the commit # 2**16
Lover-of-round-numbers--ly yours,
--
. Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-3000 mailing list
Python-3000@python.org
http://mail.pyt
2008/6/27 Guido van Rossum <[EMAIL PROTECTED]>:
> Only if you didn't know that b'' is an alternative to bytes(). The b''
> notation is so much more compact and so much more helpful that I
> really don't want to go back to it. We will somehow have to deal with
> this through education and document
2008/6/26 Georg Brandl <[EMAIL PROTECTED]>:
> Yes. Bytes objects are sequences of bytes, which are integers.
> So, in short, this is the way they work.
I think that the OP confusion comes from the representation.
We have a data type called bytes. They are sequences of bytes. So, I build one:
>>
2008/6/13 Barry Warsaw <[EMAIL PROTECTED]>:
> My proposal is this: I will spin another release this coming Wednesday, June
> 18. If we can get both the 2.6 and 3.0 buildbots green by then, and close
> out all remaining release critical bugs, then Wednesday's release will be
> beta 1. In that cas
Hi all :)
Is already planned the moment when "trunk" will mean Py 3, and the Py
2 development will be carried on in a branch?
Thanks!
--
. Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-3000 mailing list
P
2008/5/3, Guido van Rossum <[EMAIL PROTECTED]>:
> as needed. I suggest that we preface the 2.x-specific things with
> words like "in Python 2, ..." but by and large focus the style guide
> on Py3k. We could even migrate the rules that are only relevant to 2.x
> to an Appendix-like chapter. Tha
2008/4/30, Nick Coghlan <[EMAIL PROTECTED]>:
> In the bug tracker, Alexander mentioned the possibility of removing
> __length__ and __getitem__ support from range() objects in py3k, and
> implementing only __length_hint__ instead (leaving range() as a bare-bones
> iterable). I'm starting to like
2008/4/28, Benjamin Peterson <[EMAIL PROTECTED]>:
> It seems that os.walk has more options and a cleaner interface to
> walking trees than os.path.walk does. Is there support for the removal
> this in Py3k?
+1
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.o
2008/4/29, Benjamin Peterson <[EMAIL PROTECTED]>:
> On Tue, Apr 29, 2008 at 4:09 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> > Put another way: range(n) currently works, in Py3k, for n > sys.maxsize.
> > What's the rationale for breaking that?
>
> So we can support other sequence methods. (
2008/4/26, Benjamin Peterson <[EMAIL PROTECTED]>:
> lens are forced to be <= Py_ssize_t because that's the limit put on
> sequence sizes.
But this should be a secuence issue... or not? Why I'm limiting the
general len()/__len__ infrastructure?
Thanks!
--
.Facundo
Blog: http://www.taniqu
2008/4/26 Alexander Belopolsky <[EMAIL PROTECTED]>:
> > What is range()?
> >
> > help(range) shows me that range "Returns an iterator that generates
> > the numbers in the range on demand."
>
> This is not correct in 3.x: range does not return an iterator. There is an
> iterator similar to r
2008/4/26, Benjamin Peterson <[EMAIL PROTECTED]>:
> First of all, should the length of range be completely constricted by
> Py_ssize_t? (issue 2690) Since indexing already is constrained by
> this, it would make sense to make the whole object live under that
What is range()?
help(range) shows
2008/4/24, "Martin v. Löwis" <[EMAIL PROTECTED]>:
> The advanced way of invoking some method on the object (i.e. emulating
> the for loop) is to first create an iterator from the range object.
> You can't consume the range itself: it will always contain the same
> numbers - just like you can't
Hi all!
Used to be able to do this...
>>> l = (x for x in range(10))
>>> l.__next__()
0
>>> l.__next__()
1
...I tried the following:
>>> r = range(5)
>>> r
range(0, 5)
>>> r.__next__
Traceback (most recent call last):
...
AttributeError: 'range' object has no attribute '__next__'
Which is the
2008/4/22, Andrew McNabb <[EMAIL PROTECTED]>:
> Here's a really simple example:
>
> ("bash", "-c", 'FILE="/tmp/a b c"; cat "$FILE"')
>
> That's pretty simple as a list of arguments. But if you do it as a
> single string, you get:
>
> 'bash -c \'FILE="/tmp/a b c"; cat "$FILE"\''
>
> It can ge
2008/4/22, Andrew McNabb <[EMAIL PROTECTED]>:
> That's the best thing about subprocess. Whenever I've used APIs that
> accept a single string instead of list of arguments, I've quickly
> descended into quoting hell.
I don't understand why, could you please provide me one example or two?
Thank
2008/4/22, Guido van Rossum <[EMAIL PROTECTED]>:
> I still think os.popen() should be reimplemented on top of subprocess,
> and add the same optional flags as the open() function has grown to
> indicate encoding and buffering.
os.popen() is deprecated in 2.6, with the recommendation of using t
2008/4/18, Nicholas T <[EMAIL PROTECTED]>:
> Amaury - I think it's generally cleaner code to write
> for myObject in someList:
> if myObject.fits():
>process(myObject)
> break
> than
>for myObject in someList:
> if myObject.fits():
> break
>
2008/4/8, Guido van Rossum <[EMAIL PROTECTED]>:
> Seems to be mass confusion all around. My proposal is:
>
> repr(int) ==
> str(int) == 'int'
>
> For user-defined classes, a module name will always be present, e.g.
> for class C defined in __main__:
>
> repr(C) ==
> str(c) == '__main__.C'
2008/4/8, Greg Ewing <[EMAIL PROTECTED]>:
> That's true, but it's sufficiently unlikely that a string
> such as "" could have accidentally arisen some
> other way that I don't lose any sleep over it. If weird
> things seem to be happening in some particular case, I'll
> put a repr() in to find
2008/4/2, David Pokorny <[EMAIL PROTECTED]>:
> describe, but I don't understand why the behavior of the most common
> name should be the most efficient implementation of the most common
> scenario. One could propose an alternate policy: the behavior of the
Half of the magic power of Python, IM
2008/3/26, Neal Norwitz <[EMAIL PROTECTED]>:
> We need to get the tests for Python to be more stable so we can push
> out solid releases. In order to achieve this result, we need tests
> that are *100% reliable* and fail _only when there is a problem with
+1
> Python_. While we aren't near
2008/3/16, Guido van Rossum <[EMAIL PROTECTED]>:
> they are a sufficient tool. In my day job at Google we've started to
> do all task management for our project in the bug tracker (but that
> tracker has some features that make it particularly easy). Does anyone
Like which? Something that coul
2008/3/1, Christian Heimes <[EMAIL PROTECTED]>:
> I also propose translations of the shorter text to important languages
> like French, German, Japanese, Portuguese and Spanish. I'm willing to
> help with the German translation.
/me raises his hand while saying "Spanish, Spanish!".
Which is t
2008/2/29, Guido van Rossum <[EMAIL PROTECTED]>:
> Am I the only one for whom test_profile and test_cProfile are failing
> with a current Py3k head checkout?
Both fail for me too.
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
2008/2/21, Aahz <[EMAIL PROTECTED]>:
> >From my POV, this is cruft in the builtins (I mostly do web apps) -- and
> I don't particularly like your suggestions for modifying the result of
> breakpoint() (note that Facundo wants to use gdb). Why not simply
No, no, my mistake, I also use pdb.
2008/2/21, Barry Warsaw <[EMAIL PROTECTED]>:
> good_code()
> import pdb; pdb.set_trace()
> call_buggy_code()
>
> ...
>
> good_code()
> breakpoint()
> call_buggy_code()
"import gdb;gdb.set_trace()" is my second-most-used debugging tool
(the first one is "print"), so
2008/2/8, Daniel Stutzbach <[EMAIL PROTECTED]>:
> Picture command-line usage of python. You're sitting at your prompt, and
> you run a python script. It pops up a *new* window and you have to interact
> with that. Not a great user experience. Also, piping data to or from the
> script is imposs
2008/1/14, Raymond Hettinger <[EMAIL PROTECTED]>:
> I do recommend we dump q.empty() and q.full(). The right way is to trap the
> Empty and Full exceptions. If needed qsize() is available to make your own
> less reliable checks.
+1
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
P
2008/1/7, Raymond Hettinger <[EMAIL PROTECTED]>:
> Arghh! You seem hell-bent on jamming this in. Please leave the
> decimal module alone. It does *not* need both a round() method
> and a quantize() method.
Question.
I'm so used to quantize that I don't care. And I'm, in general, -0 to
adding
an find more details here:
http://us.pycon.org/2008/sprints/.
Thank you very much, and happy coding!
Facundo Batista, PyCon 2008 Sprint Coordinator
David Goodger, PyCon 2008 Chair
___
Python-3000 mailing list
Python-3000@python.org
http://mail
2007/12/6, Brett Cannon <[EMAIL PROTECTED]>:
> The plan is to get this done by summer. While that might seem like a
> long ways off, this is open source, so everyone's time is restricted.
Note that you could propose an sprint in PyCon 2008 for this...
> of my PEPs end up being heavily cut back
2007/11/30, Mark Summerfield <[EMAIL PROTECTED]>:
> BTW I notice that decimal.Decimal() numbers can't be used with the 'e',
> 'f', or 'g' formats. I know that these numbers aren't floating-point
> under the hood, but this still seems a bit counter-intuitive to me.
Adding __format__ to the Decimal
2007/11/25, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Am I the only person for whom test_asynchat is hanging? If it's not already
> a known issue let me know and I'll try and characterize it a bit better than
> "it hangs".
As this not happens in all the systems, it'd be great if you could
debug i
2007/11/2, Guido van Rossum <[EMAIL PROTECTED]>:
> Ah, but now try it in the py3k-pep3137 trunk...
>
> Python 3.0a1+ (py3k-pep3137, Nov 1 2007, 19:17:57)
> [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> str(b"hola")
> "
2007/11/1, Guido van Rossum <[EMAIL PROTECTED]>:
> Currently (in 3.0), "".join() automatically applies str() to the
> items of , *except* if the item is a bytes instance -- then it
> raises a TypeError. Is that proper behavior? The alternative is to
I'd prefer to *always* apply the str() function
2007/11/1, Guido van Rossum <[EMAIL PROTECTED]>:
> I could leave this all up to the 3.0 application, which would have to
> "fix up" any bytes in the pickle it receives explicitly if it wants
> to. Alternatively, I could add an encoding option to the pickle
> loading APIs (and for full flexibility
2007/10/5, Mark Summerfield <[EMAIL PROTECTED]>:
> Although re.substitute() would work (and be better than sub), I think
> re.replace() is better and more consistent regarding the rest of the
> library.
+1, happened twice to me, different jobs, that a colleague came to me
asking why there was no
2007/9/28, Rob Crowther <[EMAIL PROTECTED]>:
> a) MPF() now takes a float or integer argument because mpf_set_str is just
Rob, there has been a *lot* of discussion about this for Decimal (see
the PEP and discussions in python-dev and python-list around the PEP
date).
The main issue here is what
2007/9/25, Rob Crowther <[EMAIL PROTECTED]>:
> a float. At this point, I'm able to use it as a stripped down drop in
> replacement for Decimal. It's also much, much faster.
Didn't understand this phrase. You're able to use it, after stripping
it down, as a replacement of Decimal? Or you're able t
2007/9/4, Greg Ewing <[EMAIL PROTECTED]>:
> I think its main use is as a source of functions for passing
> to map(). Unless I'm mistaken, that's still going to be faster
Or to sort:
>>> import operator
>>> l = [(1, 3), (2, 2)]
>>> sorted(l, key=operator.itemgetter(1))
[(2, 2), (1, 3)]
>>>
Regar
48 matches
Mail list logo
