2007/12/7, Sean Reifschneider <[EMAIL PROTECTED]>:
> FYI: I have no real interest in this, a friend of mine is interested in
> this, just from a "why is powertop saying pygtk is waking up 10 times a
> second on my laptop?" standpoint. So I'm just trying to shepherd this.
As a Gnome user, I'm per
2007/11/1, Facundo Batista <[EMAIL PROTECTED]>:
> > I think the keyword and keywords interface can be improved. Do you have
> > any plans in that direction?
>
> Surely!
>
> But, no, I have no plans to do it, as I can not make cgi scripts in my
> hosting, so t
2007/12/8, Ron Adam <[EMAIL PROTECTED]>:
> Looks much improved! :-)
Thanks!
> Maybe components and keywords could be combined together and use check
> boxes so more than one item at a time can be selected?
Regarding the combination, I don't think so: I'm just showing the info
from the Tracker
2007/12/10, Ron Adam <[EMAIL PROTECTED]>:
> This is from the search page of the tracker.
>
>
> don't care
>
>
> accepted
>
> duplicate
> fixed
> invalid
> later
> out of date
> postponed
>
> rejected
> remind
> wont fix
>
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-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailm
Hi!
The issue 1689 [1] proposes a patch to backport the PEP 3141 [2], A
Type Hierarchy for Numbers, to the trunk.
The patch applies cleanly, and all tests pass ok (of course, even the
new ones that are specific to this).
The patch misses documentation and lines for the NEWS file, I'll ask
for th
2008/1/3, Raymond Hettinger <[EMAIL PROTECTED]>:
> I think Py2.6 and Py2.5 should be treated with more respect. Will
> backporting this change can only cause relief or create
> headaches?. By definition, the Py3.0 release was supposed to be the one big
> incompatible set of changes. Backport
2008/1/2, Raymond Hettinger <[EMAIL PROTECTED]>:
> How about a new, simpler syntax:
>
> * import threading or dummy_threading as threading
>
> * import xml.etree.CElementTree or cElementTree or elementree.ElementTree as
> ET
>
> * from cStringIO or StringIO import StringIO
>
> * import readline o
2008/1/3, Titus Brown <[EMAIL PROTECTED]>:
> What needs to be done with 2.6? I'm happy to review patches, although
> even were commit access on offer I'm too scatterbrained to do a good job
> of it.
We have 109 patches open for 2.5 [1], and 118 patches open for 2.6 [2].
Note that the added numb
2008/1/4, Jeffrey Yasskin <[EMAIL PROTECTED]>:
> I haven't seen any answers to the original question. It looks like
> Decimal is decided by 2.5 too: return a float from everything.
> Rational, being a completely new type, is up to you guys, but because
> new support for the conversion routines see
2008/1/3, Titus Brown <[EMAIL PROTECTED]>:
> The question is, is reviewing patches a good place to contribute? Also,
> if I (and others) could have a "core mentor" with commit access, that
> might streamline things. As it is, I am worried that patch reviews will
For a core_mentor/padawan (wink)
2008/1/4, A.M. Kuchling <[EMAIL PROTECTED]>:
> I've updated the bug day pages in the wiki:
This one should be also updated:
http://wiki.python.org/moin/MissingFromDocumentation
All the issues pointed by it are already closed (or don't exist (!)).
> http://wiki.python.org/moin/Python
2008/1/4, Mark Dickinson <[EMAIL PROTECTED]>:
> That seems a little peculiar to me: wouldn't it be more natural to have
> round(Decimal_instance) return another Decimal?
Yes.
Now I find that now round() delegates its work to __round__:
http://docs.python.org/dev/library/functions.html#round
2008/1/5, Art Rasmussen <[EMAIL PROTECTED]>:
> Added Python to the referenced article (because I believe Python
> should be seen everywhere C#, PHP, Visual Basic, etc., are seen).
> Please let me know if the article needs updating/fixing.
Well, don't know.
It talks about the rounding in Python,
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
2008/1/18, Guido van Rossum <[EMAIL PROTECTED]>:
> I don't think any of that is necessary. I would rather have the
> following two in the language by default (see my response to Terry and
> Raymond):
>
> bytes is an alias for str (not even a subclass)
> b"" is an alias for ""
+1
--
.Facundo
2008/1/24, Guido van Rossum <[EMAIL PROTECTED]>:
> > So you won't be able to construct an int from a float? That sucks (and
> > is unintuitive).
>
> Yes, you can, but you have to specify how you want it done by using
> trunc() or round() or ceil() or floor(). (In 3.0, round(x) will return
> an int
2008/1/25, Jeffrey Yasskin <[EMAIL PROTECTED]>:
> decision comes to be that int(float) should be blessed as a correct
> way to truncate a float, I'd agree with Raymond that trunc() is just
> duplication and should be eliminated. I'd, of course, rather have a
> spelling that says what it means. :)
2008/1/25, Paul Moore <[EMAIL PROTECTED]>:
> - int() has to stay in builtins for obvious reasons.
+1
> - put *all* of trunc, ceil, floor, round into math.
+1
> - make int(float) an error
-0 (you should be able to convert between builtin datatypes without
the use of a module). +1 to keep it
2008/2/4, Brett Cannon <[EMAIL PROTECTED]>:
> The 1 MB PDF can be found at
> http://www.cs.ubc.ca/~drifty/pycon/sprint_tutorial.pdf . If you find
> any bad info or some info that is really lacking, let me know. But
Brett, please tell me when you have a kind of finished version of
this... I want t
2008/2/14, Giampaolo Rodola' <[EMAIL PROTECTED]>:
> asyncore and asynchat are in a difficult position right now since a
> lot of patches for both modules are pending and no decisions are
> taken.
> In detail I'm talking about patches 1519, 1541, 2073 and 1736190 which
> is the most important o
Hi!
Don't now if always, or in the last few months where I've been
following the issues more closely, but I found that are appearing a
lot of small RFEs in the tracker.
These normally are small but not trivial things. In most cases when I
read them I think "Mmm, yes... it won't hurt to have it, b
2008/2/19, Georg Brandl <[EMAIL PROTECTED]>:
>
> Problem is, we don't have an 'rfe' keyword anymore :)
>
Shall we grow one again?
What would happen with PEP 42? will it be deprecated?
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
2008/2/19, "Martin v. Löwis" <[EMAIL PROTECTED]>:
> >> Problem is, we don't have an 'rfe' keyword anymore :)
> >
> > Shall we grow one again?
>
> What's wrong with the rfe type? Why does it have to be a keyword?
For me, none. I'm just trying to converge the mail thread to a result, :)
As far as
2008/2/20, "Martin v. Löwis" <[EMAIL PROTECTED]>:
> - no selection -118
> wont fix189
> works for me62
> accepted310
> fixed 611
> duplicate 75
> later 17
> invalid 73
> postponed 6
> out of date 193
> remind 1
> rejected180
Thi
2008/2/21, Virgil Dupras <[EMAIL PROTECTED]>:
> I don't see why would want to run this query on open tickets. What
> would it tell you? How many old issue there is? You can already know
> that with a simple search. The goal of this script is to know the
> resolution of tickets that had a 6+ mon
2008/2/21, Gregory P. Smith <[EMAIL PROTECTED]>:
> > That sounds eminently sensible. So sensible there should be
> > documentation that tells us to do that. Drat it, where's Brett Cannon
> > when you need him? :-)
>
> I'm always faced with a tiny quandry when closing a fixed bug that had a
> patch
2008/2/21, Brett Cannon <[EMAIL PROTECTED]>:
> Something like "handle" or "resolved". An issue is an issue and we
> wanting a single way to say the issue was closed because what is was
> about was handled seems reasonable.
+1 to resolved.
--
.Facundo
Blog: http://www.taniquetil.com.ar/pl
2008/2/21, "Martin v. Löwis" <[EMAIL PROTECTED]>:
> It's possible to "retire" objects in Roundup: certain resolution values
> would still be present and referenced by issues that use it, but they
> would not appear anymore in the drop-down list.
We can go one step further: If we change "fixed"
2008/2/22, Nick Coghlan <[EMAIL PROTECTED]>:
> Combining 'fixed' and 'accepted' into something generic like 'resolved'
> is no good, since 'not a bug' is also a resolution from our point of
> view, even if the original author of the issue may not particularly like
> the answer :)
First two de
2008/2/22, Nick Coghlan <[EMAIL PROTECTED]>:
> Now, dropping 'later', 'postponed' and 'remind' from the list of
> available resolutions is something I could wholeheartedly support. If we
> want to postpone something to a later release, we should put an
> appropriate entry in the version list.
2008/2/22, Brett Cannon <[EMAIL PROTECTED]>:
> I think Martin is right that someone needs to take the lead and do a
> complete review of how issues are handled. That way we can do a change
> in one big batch to something that works better for Python.
+1
What about a couple of hours in the Pyth
2008/2/23, Virgil Dupras <[EMAIL PROTECTED]>:
>
> The flow seems healthy to me.
>
What I don't see healthy is that we have, per week, around 30 issues
more open (30 is the difference between those closed, and the new
ones).
So, the curve is always going up... fast.
--
.Facundo
Blog: http
2008/2/23, Steve Holden <[EMAIL PROTECTED]>:
> A larger team (not necessarily all committers) could help us improve
> quality and reduce the issue count. Deleting issues purely on grounds of
Exactly, that's why I love Python bug days.. and I'm pushing this hard
in Argentina!
In the January one
Hi!
In today's bug day, an Argentinian colleague called my attention over
the issue 1746071.
This issue is about mutex:
"""The mutex module defines a class that allows mutual-exclusion via
acquiring and releasing locks. It does not require (or imply)
threading or multi-tasking, though it could b
2008/2/23, Guido van Rossum <[EMAIL PROTECTED]>:
> According to the docstring it's only meant to be used with sched.py.
> Please don't try to make it work with threads! Maybe this needs to be
> moved into a "simulations" package in 3.0?
Ok, I'll close the issue with this, and forward this ma
2008/2/23, Facundo Batista <[EMAIL PROTECTED]>:
> Ok, I'll close the issue with this, and forward this mail to the
> stdlib reorg for proper handling.
1. Done
2. It was already taken care of in the stdlib reorg sheet (it will be
removed, or at least its api hidden, i
2008/2/23, Stephen J. Turnbull <[EMAIL PROTECTED]>:
> If that curve ever turns down, it means that users are giving up on
> Python as a tool for solving ever harder problems. That's where it
> gets scarey.
It depends. If that happens because no new issues are found, maybe (it
could happen als
2008/2/25, A.M. Kuchling <[EMAIL PROTECTED]>:
> Should we have one next month? The PyCon sprint will fall on Monday
> through Thursday, and few people not at PyCon will be available during
> the work week. OTOH, if we scheduled a bug day for the 29th, that's
> two weeks after the conference,
All fail in test_compiler.py.
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python
2008/2/25, Christian Heimes <[EMAIL PROTECTED]>:
> Thomas Herve has worked out a patch: http://bugs.python.org/issue2177
After reviewing, testing and etc, I commited it. Let's see the buildbots! :)
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
2008/2/25, Facundo Batista <[EMAIL PROTECTED]>:
> 2008/2/25, Christian Heimes <[EMAIL PROTECTED]>:
>
> > Thomas Herve has worked out a patch: http://bugs.python.org/issue2177
>
> After reviewing, testing and etc, I commited it. Let's see the buildbots! :)
So
2008/2/25, Thomas Hervé <[EMAIL PROTECTED]>:
> I've worked on that problem during the bug day. I've open a ticket with
> a patch at http://bugs.python.org/issue2168.
Most of the buildbots are green now!!!
Thank you all! This community is as awesome as Python itself, ;)
Three remains in red, t
2008/2/26, "Martin v. Löwis" <[EMAIL PROTECTED]>:
> They check out bsddb from subversion, see Tools/buildbot/external.
> If you don't trust that they did so correctly, edit the script to
> remove bsddb, check that in, wait for them to delete it, then revert
> the script, check in again, and see
2008/2/28, James Tauber <[EMAIL PROTECTED]>:
> The Google Summer of Code is on again and I've been asked to coordinate
> the PSF's involvement.
These are great news, specially the second one, :)
Regards,
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
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/3/4, Trent Nelson <[EMAIL PROTECTED]>:
> Spent some time on my buildbot (x86 2k8 trunk) this morning trying to track
> down why test_bsddb3 is failing (trunk with db-4.4.20). The first test that
> fails is this:
Thank you very much!!
Regards,
--
.Facundo
Blog: http://www.taniqueti
2008/3/5, Guido van Rossum <[EMAIL PROTECTED]>:
(Bringing this from python-ideas, Guido is talking about PEP 3135)
> Ehhh! The PEP's "reference implementation" is useless and probably
> doesn't even work. The actual implementation is completely different.
> If you want to help, a rewrite of the
Hi!
My head crashed into this:
>>> class C(object):
...: pass
...:
>>>
>>> dir(C)
['__class__', ...]
>>> C.__bases__
(,)
Why __bases__ does not appear in dir()?
Is there a good reason for this or should I file a bug?
Thanks!
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
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/19, Barry Warsaw <[EMAIL PROTECTED]>:
> > +1 to assert* from me. the fail* variants always feel like
> > double-negatives. I also always use assertTrue instead of assert_. But
> > I don't care enough to argue about it. :)
+1 to the plain affirmative propositions (assert*) instead of the
2008/3/20, Andrew McNabb <[EMAIL PROTECTED]>:
> Since we officially encourage people to spawn processes instead of
> threads, I think that this would be a great idea. The processing module
> has a similar API to threading. It's easy to use, works well, and most
> importantly, gives us some pl
2008/3/25, Mark Dickinson <[EMAIL PROTECTED]>:
>
> I'd call this a bug. The change is an accident, a side-effect of the fact
> that in 2.5.1 the coefficient (mantissa) of a Decimal was stored as a
> tuple, and in 2.5.2 it's stored as a string (which greatly improves
> efficiency).
> Clearly i
2008/3/25, Nick Coghlan <[EMAIL PROTECTED]>:
>
> Anyway, +1 on coercing the mantissa to a str() instance in 2.5.
>
I don't know about 2.5, I'm sure about 2.6.
> To fix this, decimal probably needs to grow something like the following
> near the top of the module:
>
> try:
>_bytes = byte
2008/3/25, Mark Dickinson <[EMAIL PROTECTED]>:
> So int and float accepts bytes, while complex, Decimal and Fraction do
> not...
I'm -1 to accept bytes as input for Decimal, I don't see a case of
use, and I think that conceptually there's no reason to do it.
Of course, I can be wrong, ;)
Regard
2008/3/25, Alex Martelli <[EMAIL PROTECTED]>:
> > Since we have some strong use cases at least for the bytes->int case,
> > consistency then suggests that the other numeric types should all accept
> > bytes as well (interpreting them as ASCII encoded strings).
>
> +1 -- it seems very practica
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/26, Christian Heimes <[EMAIL PROTECTED]>:
> > I'm okay with bytearray not being subclassable in 2.6 as a temporary
> > measure. I wouldn't want that to leak into 3.0 though, and I'd rather
> > have it subclassable in 2.6 as well. I wonder why it doesn't work in
> > 2.6 but does work in 3
2008/3/26, Christian Heimes <[EMAIL PROTECTED]>:
> Correct!
>
> The bytearray type and the new IO system are now backported to Python 2.6.
Thank you very much for this effort!
Regards,
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
__
2008/3/26, Mark Dickinson <[EMAIL PROTECTED]>:
> I think it's still worth considering a hybrid implementation of Decimal:
> C code for the basic integer arithmetic (that is, supply a long int
> replacement whose underlying implementation works in base a
> power of 10), and Python for all the comp
2008/3/26, Nick Coghlan <[EMAIL PROTECTED]>:
> Basically, while it makes a lot of sense to move the *arithmetic* to C
> (as Mark mentioned in his other post), there's a lot of ancillary stuff
> related to flags and exceptions and context handling that is much easier
> to handle in Python.
Tha
2008/3/30, "Martin v. Löwis" <[EMAIL PROTECTED]>:
> > If you'd like, I can merge the rest.
>
> If you have the time to figure it all out, sure.
> I found that quite a tedious task, and had to spent
> on some patches quite a long time to figure out what
> they do, and what the 3.x equivalent sho
2008/3/31, Christian Heimes <[EMAIL PROTECTED]>:
> In most cases it's easy. Usually it takes me less than 20 minutes per
> day to merge the chances from trunk -> py3k. In this particular case
> several obstacles come together. The changes in the AST and parser code
> aren't trivial, I'm not fam
2008/4/1, Tim Golden <[EMAIL PROTECTED]>:
> If this is the thing to do, presumably test_support should
> grow a "remove_file" which does something of this sort?
+1 (I was thinking exactly that).
Regards,
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar
2008/5/1, Georg Brandl <[EMAIL PROTECTED]>:
> There may be more implications and surprising behavior surrounding this.
>
> I know that the implementation is a compromise, but I'd rather see a
> super()
> whose full semantics can be explained to programmers without using to
> "cell variable",
2008/5/7, A.M. Kuchling <[EMAIL PROTECTED]>:
> This would be a good chance for Py3K to dump httplib/urllib/urllib2
> and use some more modern library.
Which modern library do you propose?
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
2008/5/11, Brett Cannon <[EMAIL PROTECTED]>:
> It's a common enough use-case, so I think it makes sense. With the
> cost being so minimal to add support I think this one use-case alone
> is enough to justify adding the support.
+1
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr
2008/5/13, Steven D'Aprano <[EMAIL PROTECTED]>:
> Perhaps what we need is a more flexible enumerate function?
> enumerate(iterable, start_at_index=0, count_from=0)
+1 to provide both options: they're not intrusive (as I can keep using
enumerate without those), and having both helps in the under
2008/5/13 Jesse Noller <[EMAIL PROTECTED]>:
> I am looking for any questions, concerns or benchmarks python-dev has
> regarding the possible inclusion of the pyprocessing module to the
> standard library - preferably in the 2.6 timeline. In March, I began
+1 to include this module in the library
Hi!
A thread in PyAr raised the question that, considering that strings
are immutable, why a slice of a string is a copy and not a reference
to a part of that string.
I couldn't answer why, so I'm asking here...Is it because the
reference counting will be complicated? Is it because it'd be
ineffi
2008/5/22 Oleg Broytmann <[EMAIL PROTECTED]>:
> I remember some discussions... let me see... google to help... aha:
>
> http://mail.python.org/pipermail/python-3000/2006-August/003224.html
> http://mail.python.org/pipermail/python-3000/2006-August/003242.html
These descussions are too general,
2008/5/22 Scott Dial <[EMAIL PROTECTED]>:
> If we changed Python to slice-by-reference, then tomorrow someone would be
> asking why it isn't slice-by-copy. There are pros and cons to both that are
Which are the cons of slice-by-reference of an immutable string?
> dependent on your application.
2008/5/22 Isaac Morland <[EMAIL PROTECTED]>:
> By contrast, the worst that can happen with no sharing is that performance
> and memory use is what you expect - the only "bad" is the apparent missed
> opportunity for optimization.
Exactly, "apparent".
Also, this could be handled like a "good writ
2008/5/22 Facundo Batista <[EMAIL PROTECTED]>:
> I couldn't answer why, so I'm asking here...Is it because the
> reference counting will be complicated? Is it because it'd be
> inefficient in other way? It's something else? Or is something that
> could be d
2008/6/6 James Thomas <[EMAIL PROTECTED]>:
> Hi All,
> I'm a new developer with Python. I have a solid knowledge of both Python and
> C. Are there any tasks that would be suitable for a beginner to the Python
> codebase? I haven't been able to find a list of such tasks on python.org or
> bugs.pyth
2008/6/6 Benjamin Peterson <[EMAIL PROTECTED]>:
> I always find it hard to find a test I'm looking for in a directory
> with 365 different tests in it. Also grouping tests by function will
> hopefully help reduce duplication and it more intuitive.
Intuitive to who taking into account which groupi
2008/6/12 Barry Warsaw <[EMAIL PROTECTED]>:
>> function:: active_count()
>> method:: Thread.get_name()
>> method:: Thread.is_alive()
>> method:: Thread.is_daemon()
>> method:: Thread.set_daemon(daemonic)
>
> +1 on opting for properties in the specific cases here where it makes sense.
I'm +1
2008/6/12 anton <[EMAIL PROTECTED]>:
> ping works but http://bugs.python.org giges after a timeout:
I can enter into it.
Also note that my issues showing system [1] was updated 6.5 hours ago,
so it was up at that time (my system goes and get some info twice a
day, you have the "last updated" inf
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
2008/6/21 Neil Muller <[EMAIL PROTECTED]>:
> Could some one have a look at the suggested fix for issue 2722? While
> not a particularly common problem, it can be an annoyance, and the
> patch looks reasonable.
I'm on it... Python Bug Day!
--
. Facundo
Blog: http://www.taniquetil.com.ar/plog/
P
Hi all!
In Python Argentina we get together in two places, Buenos Aires and
Santa Fe, and worked out around 10-12 bugs, which is around the half
of the total for both days, so I'm very happy, :)
We even had a Python logo shaped cake, see, see [1].
Did you participate? What do you think it's the
2008/6/25 Justin Mazzola Paluska <[EMAIL PROTECTED]>:
> The idea behind the patch is that it's sometimes useful to disable
> tests without removing them from the TestCase. For example, a
> co-worker and I have a module with a few tests that will fail for the
> forseeable future because we haven't
(sorry for the crossposting)
Do you know what happened with "http://us.pycon.org/";?
Thank you!
--
. Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
2008/7/3 David Goodger <[EMAIL PROTECTED]>:
> Jeff fixed it. URL rewriting was off by mistake.
Thanks! :)
--
. Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
Python-Dev@python.org
http://m
2008/7/30 Matt Giuca <[EMAIL PROTECTED]>:
> 2. Default to UTF-8.
> In favour: Matt Giuca, Brett Cannon, Jeroen Ruigrok van der Werven
> Pros: Fully working and tested solution is implemented; recommended by
> RFC 3986 for all future schemes; recommended by W3C for use with HTML;
> UTF-8 used by al
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-Dev mailing list
Python-Dev@python.org
http://mail.pytho
The test_raiseMemError() in test_unicode.py is complicating me the
regression tests: tries to use all the memory in my system, which
starts to swap as crazy, and almost freezes everything. When the test
finishes (always pass ok), I have all the memory flushed so it take a
few seconds to go back to
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
2008/8/16 Antoine Pitrou <[EMAIL PROTECTED]>:
> If the test does allocate the very large string, it means MemoryError isn't
> raised, which defeats the purpose of the test.
I do *not* want to remove the test.
I just want to execute it *only* when I run "-u all" or "-u memory",
not everytime I ru
2008/8/16 "Martin v. Löwis" <[EMAIL PROTECTED]>:
> See bug http://bugs.python.org/issue3556
>
> If no solution is forthcoming quickly, I recommend to remove/disable the
> test.
The Antoine patch works ok for me, and solves the whole issue.
I'm on linux, if somebody can give it a try in another p
2008/8/21 Guido van Rossum <[EMAIL PROTECTED]>:
> The two, quite separate, questions, then, are (a) how much work would
> it be to upgrade to version 5.1.0 of the database; and (b) would it be
> acceptable to do this post-beta3 (but before rc1). If the answer to
> (b) is positive, Google can help
2008/8/28 Barry Warsaw <[EMAIL PROTECTED]>:
> bots we should "trust" to judge the health of the trees. I don't think the
> current list needs to be set in stone, and in fact several of the "stable"
> bots have had simple svn or other non-tree related problems for a while.
Maybe a good requisite
2008/8/28 Antoine Pitrou <[EMAIL PROTECTED]>:
> By that metric, I fear that the only remaining buildbots would be the
> Linux/Windows x86/x64 ones. I'm not sure anyone here, for example, cares
> really
Note that I meant to "move from unstable to stable, starting from the
actual state", not to "d
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
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/10/5 Kevin Teague <[EMAIL PROTECTED]>:
> on Python 3 after running it through 2to3. The source code is different so
> that to me suggests different version numbers - but the API will be the
> same, so maybe the same version number should be used? That is should there
> be?
>
> foobar-1.0-py2.
2008/10/5 "Martin v. Löwis" <[EMAIL PROTECTED]>:
>>> foobar-1.0-py2.6.tar.gz
>>> foobar-1.0-py3.0.tar.gz
>>
>> More likely, in this way:
>>
>> foobar-1.0-py2.tar.gz
>> foobar-1.0-py3.tar.gz
>
> How do you implement this in distutils? People probably won't rename
> the files from how sdist names th
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
Hi all! I generated this info for other list, thought that it could be
valuable to share it here...
I've been collecting some statistics since January, as I'm concerned
about the issue of tickets quantity just getting higher.
I've been saving twice a day (everytime I generate this [0] info), the
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
201 - 300 of 379 matches
Mail list logo
