[Python-Dev] No 2.x->3.x porting documentation?
I apologize if this has been discussed here or elsewhere already. I'm offline as I write this so my only source of guidance is what I find in my Subversion checkouts. I'm making a naive stab at converting nose to Python3 so I can hopefully run the lockfile test cases under Python 3. (Again, I'm offline and have no idea at this point if it's been done already.) I ran 2to3 then tried installing. I got an immediate error about the compiler.consts module being missing. (All nose does is import CO_GENERATOR from compiler.consts.) I found that in the inspect module. Then it complained about ClassType being missing from the types module. I found no mention of changes to the types module in Misc/NEWS or Doc/whatsnew/3.0.rst. I didn't find anything which looked like a "porting" document. If neither of these changes could be handled by 2to3 I think it would have been useful to at least document the changes (in whatsnew/3.0.rst?) and maybe offer humans some workaround ideas. If there is a wiki page collecting porting wisdom it should be referenced. If I'm missing something fundamental about how people are expected to approach porting 2.x code to 3.x, please let me know. Thanks, Skip ___ 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
Re: [Python-Dev] Bug tracker house cleaning.
Raymond> ISTM, that when closing duplicate bug reports, both should Raymond> reference one another so that the combined threads don't get Raymond> lost. RT has a merge feature which allows you to take a duplicate an merge it into another ticket. This merges the chain of comments, cc's requestors, etc. Skip ___ 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
Re: [Python-Dev] How do I get commit access?
Christian> CPython has a stricter policy than most other Python related Christian> projects. Indeed. I'd be willing to grant you checkin privileges for SpamBayes simply because because Christian recognized you and you seem willing to roll up your sleeves. Do you do Windows? Skip ___ 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
Re: [Python-Dev] How do I get commit access?
>> Indeed. I'd be willing to grant you checkin privileges for SpamBayes >> simply because because Christian recognized you and you seem willing >> to roll up your sleeves. Do you do Windows? Chris> The irony that Thunderbird put this in my spam folder based on Chris> its heuristics is not lost on me ;-) So, when can you start? :-) S ___ 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
Re: [Python-Dev] running the tests...
>> My personal preferences: >> >> Thorough: ./python -m test.regrtest -uall >> Typical: ./python -m test.regrtest >> Specific: ./python -m test.regrtest test_mod1 test_mod2 Chris> This looks good, I assume this would work on Windows too? I believe so, but you should still get a real OS. Skip ___ 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
Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa
Glyph> ... which is exactly why I have volunteered to explain to someone Glyph> how to separate the core event-loop bits (suitable for inclusion Glyph> in the standard library) from the huge pile of protocol Glyph> implementations which are not necessarily useful. Neil> This sounds great. I'm interested on working on this since it Neil> scratches an itch of mine but I don't know if I will have time. Neil> Do you think if this part of Twisted became part of the standard Neil> library that it would be used by Twisted or would it continue to Neil> have its own version? Anybody interested in working on this at a PyCon Sprint? I won't be attending the conference proper, but plan to spend a couple days sprinting, one on Mailman/SpamBayes integration and one on Python core stuff. This might fit well into my Python core "slot". I will probably have little time before the sprint to do much, but any brain dumps or Twisted pointers people could give me in the interim would be appreciated. Skip ___ 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
Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa
Glyph> I'll try to make sure we get those notes to you in advance of the Glyph> sprints :). I should be at the Twisted sprint the whole time - Glyph> will you be at the physical sprint, or following along at home? Thanks. I will be at the physical sprints. (I live in the Chicago area.) Skip ___ 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
Re: [Python-Dev] draft 3.1 release schedule
>>> You might also want to collect a list of serious changes that you >>> want in this release; http://bugs.python.org/issue4847 Not yet fixed. Needs: * Decision about the correct fix (I think it will involve an API change). * Test case and a patch. * Probably small documentation changes as well. I'm wiped out this evening. I'll try to look into it, but I suspect it might require a bit more time than I have in the next day or two. Skip ___ 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
Re: [Python-Dev] python-3000 is still mentioned on the mailing lists page
David> I just noticed that the python-3000 list is still mentioned on David> http://www.python.org/community/lists/. Thanks. I passed your note along to the postmaster(s). Skip ___ 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
Re: [Python-Dev] Multiprocessing on Solaris
Jesse> Known issue: Jesse> http://bugs.python.org/issue3110 Jesse> I haven't had time to look into it, I was planning on working on Jesse> many of the mp bugs during the sprint at pycon. Jesse, I will be at the sprints for a couple days and should be able to test things out on Solaris or let you look over my shoulder as we poke around the machines at work if you need. Skip ___ 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
Re: [Python-Dev] "setuptools has divided the Python community"
Is setuptools/distutils/whatever on the agenda for the tomorrow's language summit? Or is there some other get-together at PyCon for this? Skip ___ 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
Re: [Python-Dev] "setuptools has divided the Python community"
Barry> In fact, I think it /has/ to. I'll go further and say that I'm Barry> very wary of using easy_install and the like to install Barry> non-distro provided packages into the system Python. Give that man a ceegar. The pyjamas author seems to have a different opinion about installing stuff into /usr without working with the system's packaging mechanism: http://bugs.python.org/setuptools/issue63 I don't understand how that can possibly be manageable. Skip ___ 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
Re: [Python-Dev] "setuptools has divided the Python community"
>> http://bugs.python.org/setuptools/issue63 >> >> I don't understand how that can possibly be manageable. >> Steve> Note that the issue contains a broken link. Fixed. Looks like a Roundup bug. Skip ___ 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
Re: [Python-Dev] "setuptools has divided the Python community"
Tres> Exactly: I never use easy_isntall to put packages into the system Tres> python. in fact, I only use it inside a virtalenv-generated Tres> isolated environment. While standing in line for lunch today, someone (don't know his name) suggested that easy_install needs an --i-am-an-idiot flag which would have to be used to force it to install packages in to the system's space. Skip ___ 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
[Python-Dev] Python svn post-commit hook?
I'm trying to get the powers that be at work to enable post-commit hooks for our Subversion repositories. Here's the default, sans comments: REPOS="$1" REV="$2" commit-email.pl "$REPOS" "$REV" commit-watch...@example.org log-commit.py --repository "$REPOS" --revision "$REV" Does Python's post-commit.tmpl do more (or less) than this? If it's substantially different, can someone mail me a copy of what's installed? Thanks, Skip ___ 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
Re: [Python-Dev] "setuptools has divided the Python community"
Steve> Careful, Glyph. Nobody likes a smart-ass ;-) I think he'll be ok. He escaped the language summit with only minor wounds yesterday. Skip ___ 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
Re: [Python-Dev] "setuptools has divided the Python community"
mal> Zip files are great for shipping packages to the end-user, but mal> there's no need to keep them zipped once they get there. I thought one of the arguments for zip files was a performance increase (reduced stat(2) calls, etc). I may misremember though. Skip ___ 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
[Python-Dev] Partial 2to3?
Following up on yesterday's conversation about 2to3 and 3to2, I wonder if
it's easily possible to run 2to3 with a specific small subset of its fixers?
For example, people not wanting to make the 2->3 leap yet might still be
interersted in the exception handling changes ("except Foo as exc")?
Thx,
--
Skip Montanaro - s...@pobox.com - http://www.smontanaro.net/
___
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
[Python-Dev] This seems like a bug - main thread has None ident???
Looking for some quick feedback on this. I've bumped into what looks like a bug in the threading module. From the interpreter prompt: >>> import threading >>> threading.currentThread() <_MainThread(MainThread, started)> >>> print threading.currentThread().ident None The ident attribute is documented as being a number unless the thread has yet to be started. Shouldn't the main thread's ident attribute *always* be non-None? Clearly, it appears the main thread has been started. Am I missing something obvious or have I hit a bug? This is a fully updated 2.7a0 build, trunk:70878M. Skip ___ 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
Re: [Python-Dev] This seems like a bug - main thread has None ident???
skip> Am I missing something obvious or have I hit a bug? This is a
skip> fully updated 2.7a0 build, trunk:70878M.
After noting that thread.get_ident() returned a thread id but that
threading.currentThread().ident was None I concluded that it is, in fact, a
bug in the threading module. I opened a ticket:
http://bugs.python.org/issue5632
Skip
___
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
Re: [Python-Dev] CSV, bytes and encodings
>> Having read through the ticket, it seems that a CSV file must be (and >> 2.6 was) treated as a binary file, and part of the CSV module's job >> is to convert that binary data to and from strings. Antoine> IMO this interpretation is flawed. In 2.6 there is no tangible Antoine> difference between "binary" and "text" files, except for Antoine> newline handling. Also, as a matter of fact, if you want the Antoine> 2.x CSV module to read a file with Windows line endings, you Antoine> have to open the file in "rU" mode (that is, the closest we Antoine> have to a moral equivalent of the 3.x text files). The problem is that fields in CSV files, at least those produced by Excel, can contain embedded newlines. You are welcome to decide that *all* CRLF pairs should be translated to LF, but that is not the decision the original authors (mostly Andrew MacNamara) made. The contents of the fields was deemed to be separate from the newline convention, so the csv module needed to do its own newline processing, and thus required files to be opened in binary mode. This case arises rarely, but it does turn up every now and again. If you are comfortable with translating all CRLF pairs into LF, no matter if they are true end-of-line markers or embedded content, that's fine. (It certainly simplifies the implementation.) However, a) I would run it past the folks on c...@python.org first, and b) put a big fat note in the module docs about the transformation. Antoine> Therefore, I don't think 2.x is of any guidance to us for what Antoine> 3.x should do. I suspect we will disagree on this. I believe the behavior of the 2.x version of the module is easily defensible and should be a useful guide to how the 3.x version of the module behaves. >> The documentation says "If csvfile is a file object, it must be >> opened with the ___ 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
Re: [Python-Dev] CSV, bytes and encodings
Antoine> Perhaps. But without using 'rU' the file couldn't be read at Antoine> all. (I'm not sure it was Windows line endings by the way; Antoine> perhaps Macintosh ones; anyway, it didn't work using 'rb') Please file a bug report and assign to me. Does it work in 2.x? What was the source of the file? Antoine> I have to add that if individual fields really can contain Antoine> newlines, then the CSV module ought to be smarter when /saving/ Antoine> those fields. I've inadvertently tried to produce a CSV file Antoine> with such fields and it ended up wrong when opened as a Antoine> spreadsheet (text after the newlines was ignored in Gnumeric Antoine> and in OpenOffice, while Excel displayed a spurious additional Antoine> row containing only the text after the newline). Sounds like you have a budding test case. Of course, the problem with CSV files is that there is no standard. In the above paragraph you named three. The CSV authors chose Excel's behavior as the measuring stick. Still, that's not written down anywhere. You have to read the tea leaves. Skip ___ 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
Re: [Python-Dev] Mercurial?
After the private hell I've gone through the past few days stumbling around Mercurial without really understanding what the hell I was doing, I strongly recommend that when the conversion is complete that there is a "do it just like you did it with svn" mode available. Fortunately, this was just with my little lockfile module, so the damage was very isolated. (And perhaps "damage" is the wrong word. Someone more experienced with hg could almost certainly correct my mistakes.) I freely admit that my own misunderstanding of how Mercurial works was the primary cause of my problems. Still, until people are real familiar with what is going on, especially people like me who have little or no familiarity with dVCSs I think it's best to just treat it like Subversion if at all possible. Skip ___ 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
Re: [Python-Dev] Mercurial?
>> As for the clone time, one of our proeminent developers is, IIRC, on >> a 40 kb/s line. Perhaps he wants to step in and say whether cloning >> the trunk is a painful experience for him, or not. Dirkjan> Sure it's painful, but he only has to go through that once, Dirkjan> maybe twice. Maybe once for each currently active Subversion branch (2.6, 2.7, 3.0, 3.1)? Skip ___ 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
Re: [Python-Dev] Tools
Barry> Someone asked me at Pycon about stripping out Demos and Tools. Matthias> +1, but please for 2.7 and 3.1 only. Is there a list of other demos or tools which should be deleted? If possible the list should be publicized so that people can pick up external maintenance if desired. Skip ___ 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
Re: [Python-Dev] pyc files, constant folding and borderline portability issues
Cesare> At this time with Python 2.6.1 we have these results:
Cesare> def f(): return 1 + 2 * 3 + 4j
...
Cesare> def f(): return ['a', ('b', 'c')] * (1 + 2 * 3)
Guido can certainly correct me if I'm wrong, but I believe the main point of
his message was that you aren't going to encounter a lot of code in Python
which is amenable to traditional constant folding. For the most part, they
will be assigned to symbolic "constants", which, unlike C preprocessor
macros aren't really constants at all. Consequently, the opportunity for
constant folding is minimal and probably introduces more opportunities for
bugs than performance improvements.
Skip
___
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
Re: [Python-Dev] Evaluated cmake as an autoconf replacement
Ondrej> ... while scons and other Python solutions imho encourage to Ondrej> write full Python programs, which imho is a disadvantage for the Ondrej> build system, as then every build system is nonstandard. Hmmm... Like distutils setup scripts? I don't know thing one about cmake, but if it's good for the goose (building Python proper) would it be good for the gander (building extensions)? -- Skip Montanaro - s...@pobox.com - http://www.smontanaro.net/ "XML sucks, dictionaries rock" - Dave Beazley ___ 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
Re: [Python-Dev] pyc files, constant folding and borderline portability issues
Cesare> The only difference at this time is regards invalid operations, Cesare> which will raise exceptions at compile time, not at running Cesare> time. Cesare> So if you write: Cesare> a = 1 / 0 Cesare> an exception will be raised at compile time. I think I have to call *bt* here. This is a common technique used during debugging. Insert a 1/0 to force an exception (possibly causing the running program to drop into pdb). I think you have to leave that in. Skip ___ 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
Re: [Python-Dev] Evaluated cmake as an autoconf replacement
>> I don't know thing one about cmake, but if it's good for the goose >> (building Python proper) would it be good for the gander (building >> extensions)? Antoine> African or European? I was thinking Canadian... Skip ___ 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
[Python-Dev] ANN: deps extension (fwd)
I know the subject of external dependencies came up here in the discussion about Mercurial. I just saw this on the Mercurial mailing list. Perhaps it will be of interest to our hg mavens. Skip --- Begin Message --- Hi, I've recently cloned the deps extension, originally developed by Aleix Conchillo Flaque, and have made some improvements. I'd love to hear your comments. http://ratatanek.cz/hg/hgdeps It should work with version 1.0 and above (tested on 1.0 and 1.2.1). The extension allows you to comfortably work with external dependencies. The dependency lists are versioned and can be quickly applied with 'hg depupdate' command. The easiest way to start is to define the dependencies you'll be using. $ hg depalias gui http://ratatanek.cz/hg/gui A file named .hgdeps will appear in your working dir. Don't forget to commit! Use 'hg dep' to move and update dependencies. $ hg dep gui lib/gui v0.1 You can always check the state of your dependencies with 'hg -v depstatus'. After you make sure your project works correctly with the new dependency or the new version of an old dependency, commit your changes and then run 'hg depcommit', which will record your changes into .hgdeps file and automatically commit them. Think of this command the same way you think about 'hg tag'. You can safely run 'hg depcommit' after each 'hg commit', the dependency list will only be recorded if some changes were made. $ hg depcommit $ hg log changeset: 6:7be195f652bf tag: tip user:Martin Vejnar date:Tue Apr 07 14:19:29 2009 +0200 summary: Updated dependency list for changeset 7220338eb0ac changeset: 5:7220338eb0ac user:Martin Vejnar date:Sat Apr 04 16:44:40 2009 +0200 summary: Updated gui to v0.2 and fixed dependent code. You can also use the extension to work with svn dependencies. Read 'hg help hgdeps' for more info. I'm planning on wrapping 'hg up', 'hg st' and 'hg ci' to automatically run 'hg depup', 'hg depst' and 'hg depci', respectively. This way, the management of dependencies would be completely transparent. Hope you like it, -- Martin ___ Mercurial mailing list mercur...@selenic.com http://selenic.com/mailman/listinfo/mercurial --- End Message --- ___ 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
Re: [Python-Dev] Evaluated cmake as an autoconf replacement
>> - registration to pypi Alex> No idea what this is . http://pypi.python.org/ It is, in some ways, a CPAN-like system for Python. Skip ___ 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
Re: [Python-Dev] Issue5434: datetime.monthdelta
>>> date(2008, 1, 30) + monthdelta(1) datetime.date(2008, 2, 29) What would this loop would print? for d in range(1, 32): print date(2008, 1, d) + monthdelta(1) I have this funny feeling that arithmetic using monthdelta wouldn't always be intuitive. Skip ___ 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
Re: [Python-Dev] Issue5434: datetime.monthdelta
>> I have this funny feeling that arithmetic using monthdelta wouldn't >> always be intuitive. Jess> I think that's true, especially since these calculations are not Jess> necessarily invertible: >>> date(2008, 1, 30) + monthdelta(1) datetime.date(2008, 2, 29) >>> date(2008, 2, 29) - monthdelta(1) datetime.date(2008, 1, 29) Jess> It could be that non-intuitivity is inherent in the problem of Jess> dealing with dates and months. To which I would respond: >>> import this The Zen of Python, by Tim Peters ... In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. ... >From the discussion I've seen so far, it's not clear that there is one obvious way to do it, and the ambiguity of the problem forces people to guess. My recommendations after letting it roll around in the back of my brain for the day: * I think it would be best to leave the definition of monthdelta up to individual users. That is, add nothing to the datetime module and let them write a function which does what they want it to do. * The idea/implementation probably needs to bake on the python-ideas list and perhaps comp.lang.python for a bit to see if some concensus can be reached on reasonable functionality. (I'm a bit behind on this thread. Hopefully someone else has already suggested these two things.) Skip ___ 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
Re: [Python-Dev] Issue5434: datetime.monthdelta
Jess> If, on the other hand, one of the committers wants to toss this in Jess> at some point, whether now or 3 versions down the road, the patch Jess> is up at bugs.python.org (and I'm happy to make any suggested Jess> modifications). Again, I think it needs to bake a bit. I understand the desire and need for doing date arithmetic with months. Python is mature enough though that I don't think you can just "toss this in". It should be available as a module outside of Python so people can beat on it, flush out bugs, make suggestions for enhancements, whatever. I believe you mentioned putting it up on PyPI. I think that's an excellent idea. I've used parts of Gustavo Niemeyer's dateutil package for a couple years and love it. It's widely used. Adding it to dateutil seems like another possibility. That would guarantee an instant user base. From there, if it is found to be useful it could make the leap to be part of the datetime module. Skip ___ 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
Re: [Python-Dev] Python-Dev Digest, Vol 69, Issue 143
Tennessee> If its' the 31st of Jan, then +1 monthdelta will be 28 Feb Tennessee> and another +1 will be 28 March whereas 31st Jan +2 Tennessee> monthdeltas will be 31 March. Other possible arithmetics: * 31 Jan 2008 + monthdelta(2) might be 31 Jan 2008 + 31 days (# days in Jan) + 29 days (# days in Feb) * 31 Jan 2008 + monthdelta(2) might be 31 Jan 2008 + 29 days (# days in Feb) + 31 days (# days in Mar) * Treat the day of the month of the base datetime as an offset from the end of the month. 29 Jan 2007 would thus have an EOM offset of -2. Adding monthdelta(2) would advance you into March with the resulting day being two from the end of the month, or 29 Mar 2007. OTOH, adding monthdelta(1) you'd wind up on 26 Feb 2007. * Consider the day of the month in the base datetime as an offset from the start of the month if it is closer to the start or as an offset from the end of the month if it is closer to the end. 12 Mar 2009 - monthdelta(2) would land you at 12 Jan 2009 whereas 17 Mar 2009 - monthdelta(1) would land you at 12 Feb 2009. My mind spins at all the possibilities. I suspect we've seen at least ten different monthdelta rules just in this thread. I don't know how much sense they all make, but we can probably keep dreaming up new ones until the cows come home. Except for completely wacko sets of rules you can probably find uses for most of them. Bake, baby, bake. pillsbury-doughboy-ly, y'rs, Skip ___ 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
Re: [Python-Dev] Issue5434: datetime.monthdelta
>> "2rd of March on leap years, > ^^^ > The turd of March? Yeah, it's from a little known Shakespearean play about a benevolent dictator, Guidius van Rossumus. The name of the play escapes me at the moment, but there's this critical scene where the BDFL is in mortal danger because of ongoing schemes by the members of the PSU. His one true friend and eventual replacement, Barius Warsawvius, known as the FLUFL, tries to warn him surreptitiously about the dangers lurking all about. Barius utters this immortal quote, "Beware the Turd of March." Unfortunately, the drama of that scene tends to be lost on modern audiences. Upon hearing that famous utterance they tend to break out in laughter, especially if the audience is made up mostly of boys under the age of twelve. -- Skip Montanaro - s...@pobox.com - http://www.smontanaro.net/ "XML sucks, dictionaries rock" - Dave Beazley ___ 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
[Python-Dev] string to float containing whitespace
Someone please tell me I'm not going mad. I could have sworn that once upon a time attempting to convert numeric strings to ints or floats if they contained whitespace raised an exception. As far back as 1.5.2 it appears that float(), string.atof() and string.atoi() allow whitespace. Maybe I'm thinking of trailing non-numeric, non-whitespace characters. Skip ___ 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
Re: [Python-Dev] string to float containing whitespace
Amaury> You are maybe referring to the Decimal constructor:
Amaury>decimal.Decimal(" 123")
Amaury> fails with 2.5, but works with 2.6. (issue 1780)
Highly unlikely, since my recollection is from way back in the early days.
Also, I have yet to actually use the decimal module. :-/
Skip
___
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
Re: [Python-Dev] albatross backup
Martin> As for volumes to backup: I think /srv needs regular backup. Martin> Not sure about any of the others Backup of /usr/local/spambayes-corpus would be very helpful. Skip ___ 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
Re: [Python-Dev] [unladen-swallow] PEP 384: Defining a Stable ABI
Nick> Jeffrey Yasskin wrote: >> To decrease the annoyance of having to change source code, we could >> have Py_INCREF(x) expand to Py_IncRef(x) in ABI-compatibility mode. Nick> Forcing developers to choose between the speed of the Nick> INCREF/DECREF macros and the proposed ABI compatibility mode for Nick> the benefit of an as yet hypothetical GIL-less CPython API Nick> implementation seems more like a way to kill adoption of the ABI Nick> compatibility mode rather than a way to encourage the use of the Nick> IncRef/Decref functions. I suspect it's not really germane to this discussion but if the incref/decref functions were defined as inline would that effectively be like using the macro versions vis a vis ABI compatibility? Skip ___ 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
Re: [Python-Dev] Adding syntax for units of measure
>> Has anyone added special syntax to allow writing numeric literals with >> physical units? So you can write 12m + 34cm, and would get 12.34m. ... Georg> normally you wouldn't add units to the language itself. ... Georg> For the interactive shell, using a wrapper that allows simplified Georg> input is also a possibility, like IPython's "-profile physics" Georg> mode, or something like http://bitbucket.org/birkenfeld/phsh/ Georg> which allows you to write >>>> `1 m` + `12 cm` Georg> 1.12 m Also, check out the magnitude module (in PyPI). I use it to specify the units of the computation but allow users to input values using units which are meaningful to them. So, for example, if a value has units of time they could enter 1m or 60s and get the same internal value. Skip ___ 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
Re: [Python-Dev] I am back
Aahz> On Wed, Jul 01, 2009, Brett Cannon wrote: >> Anything happen while I was gone that I should be aware of that is >> not covered in a PEP? Aahz> Yes. In particular, Brett, you probably didn't hear that the King of Pop died last week. It was hardly mentioned in the major news outlets... Skip ___ 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
Re: [Python-Dev] hi everyone
Nick> Specifically, python-l...@python.org (also available as the Nick> newsgroup comp.lang.python). Also, if you're a complete beginner, try subscribing to tu...@python.org: http://mail.python.org/mailman/listinfo/tutor and reading through that list's ten year's worth of archived postings. (Maybe someone create a BestOfTutor wiki page?) -- Skip Montanaro - s...@pobox.com - http://www.smontanaro.net/ Getting old sucks, but it beats dying young ___ 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
Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library
Martin> I think it's too early to tell. It may be that they have not yet Martin> achieved their purpose - just let's wait fifty more years (and Martin> I'm only half-joking). So what you're really saying is we only have to wait 25 years... Skip ___ 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
Re: [Python-Dev] operator precedence of __eq__, __ne__, etc, if both object have implementations
Dino> For IronPython we wrote a set of tests which go through and define Dino> the various operator methods in all sorts of combinations on both Dino> new-style and old-style classes as well as subclasses of those Dino> classes and then do the comparisons w/ logging. It would be very nice if these complex corner cases had a set of test cases which could be run by all implementations (CPython, Jython, IronPython, PyPy, etc). I don't know. Maybe the CPython test suite serves that purpose, but it seems like it would be helpful if this sort of "validation suite" was maintained as a separate project all implementations could use and contribute to. Skip ___ 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
Re: [Python-Dev] operator precedence of __eq__, __ne__, etc, if both object have implementations
Eric> IIRC, one of the reasons for "breaking out"[1] the standard library (and Eric> its test suite) was to allow for things like this. In my opinion the standard library and the core test suite (the language validation stuff) are entirely independent beasts. I can understand pieces of the standard library not being available in one variant or another, but key semantic aspects of the language proper should be constant across implementations. That said, I agree that if the standard library is split off from CPython then the relevant portions of the test suite should go along with it. Skip ___ 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
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
Nick> +1 here as well (although we should definitely find a way to use Nick> str.format strings instead of %-format ones... come to think of Nick> it, does even the logging module support str.format style Nick> formatting in Py3k?) Assuming argparse currently works with versions of Python < 2.6 I see no reason to make such a change. This would just introduce needless differences between the version delivered with Python and the PyPI version and make it more difficult for the author to keep the two code bases in sync. Skip ___ 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
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
Martin> alpha = None Martin> beta = False Martin> options, args = getopt.getopt(sys.argv[1:],"a:b",['alpha=','beta']): Martin> for opt, val in options: ... Martin> Even though this is many more lines, I prefer it over Martin> optparse/argparse: this code has only a single function call, ... Agreed. I have never completely wrapped my brain around optparse. Getopt I just remember. Skip ___ 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
Re: [Python-Dev] Python 2.7 Mac universal builds seem broken on trunk
Ronald> I'll write some documentation on the build options on OSX, but Ronald> don't know what's the best location to do so. The top-level README file of the distribution has a "Platform specific notes" section. Seems like that would be the most logical place to stuff such info. Skip ___ 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
[Python-Dev] test_thread tracebacks
It's been awhile since I rebuilt Python and ran the test suite. This evening I noticed this on my Mac (OS X 10.5): test_thread Unhandled exception in thread started by > Traceback (most recent call last): File "/Users/skip/src/python/trunk/Lib/test/test_thread.py", line 51, in task self.done_mutex.release() thread.error: release unlocked lock Unhandled exception in thread started by > Traceback (most recent call last): File "/Users/skip/src/python/trunk/Lib/test/test_thread.py", line 51, in task self.done_mutex.release() thread.error: release unlocked lock Unhandled exception in thread started by > Traceback (most recent call last): File "/Users/skip/src/python/trunk/Lib/test/test_thread.py", line 51, in task self.done_mutex.release() thread.error: release unlocked lock Unhandled exception in thread started by > Traceback (most recent call last): File "/Users/skip/src/python/trunk/Lib/test/test_thread.py", line 51, in task self.done_mutex.release() thread.error: release unlocked lock Oddly enough, this didn't cause the test to fail. Is this a known problem? Should I open a ticket? Skip ___ 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
Re: [Python-Dev] test_thread tracebacks
>> It's been awhile since I rebuilt Python and ran the test suite. This >> evening I noticed this on my Mac (OS X 10.5): Sorry, trunk. Skip ___ 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
Re: [Python-Dev] [New-bugs-announce] [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError
Ned> Due to a change in distutils released with Python 2.6.3, packages Ned> that use setuptools (version 0.6c9, as of this writing), or the Ned> easy_install command, to build C extension modules fail ... ... Ned> Among the packages known to be affected include lxml, Ned> zope-interface, jinja2, and, hence, packages dependent on these Ned> packages (e.g. sphinx, twisted, etc.). Maybe the Python test suite should include tests with a small number of widely used non-core packages like setuptools. I realize the pybots project exists to tackle this sort of stuff in greater detail. I'm thinking more of a smoke test than a comprehensive test suite covering all external packages. Setuptools is particularly important because so many extension authors use it. If it breaks it implicitly breaks a lot of PyPI packages. Skip ___ 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
Re: [Python-Dev] Package install failures in 2.6.3
Tarek> That's why we have forked and created Distribute, to provide bug Tarek> fixes. I suspect you might need to publicize this a bit better. The first I heard of Distribute or non-responsiveness of PJE regarding setuptools was this thread. (I don't read comp.lang.python anymore. I do read python-dev and comp.lang.python.announce. Maybe I just missed it.) Tarek> Now I am astonished that we are talking about reverting changes Tarek> in Distutils that were done for bugfixes, for a third party Tarek> package that does monkey patches on Distutils. As I said, I was completely unaware of the problems you're addressing with Distribute. My guess is that many extension writers and almost certainly those people who install extensions will be similarly unaware of the issues. Skip ___ 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
Re: [Python-Dev] Package install failures in 2.6.3
Tarek> No you didn't miss it. That's probably my fault because the only Tarek> places I publicize about it are my blog (indexed in planet Tarek> python) and the distutils-SIG. Bloggers beware!!! Not everyone reads blogs. (I don't unless someone calls my attention to something of particular interest.) Even if everyone did read blogs, the risk of missing a particular post is extremely high considering the number of planet.python.org subscriptions. I don't know how many blogs are aggregated on planet.python.org but a quick scan suggests it's well over 100 at this point. Moral of the story: If you have something to announce, announce it in the proper channel: python-announce-l...@python.org. Skip ___ 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
Re: [Python-Dev] BDFL pronouncement?
>> That's absurd. There's a certain area where Guido can make >> pronouncements, but third-party packages is not it. Even if they're >> hosted on python.org infrastructure. Guido> Right. Now if you were the un-BDFL you could step in here. ;-) This whole topic seems to have a lot of people fairly agitated, so clearly it's important to a significant subset of the Python development community. Might I suggest taking this off python-dev for awhile though? I seem to recall a similar suggestion a couple days ago to take it to distutils-sig or python-ideas, but that seems to have been ignored.) I mostly tuned the entire thread out until I saw that Guido had joined in the fray (sort of). Maybe since I don't distribute a lot of Python packages it's not as important to me. Let me know when you've solved the problem. I trust you. Skip ___ 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
Re: [Python-Dev] [python-committers] On track for Python 2.6.4 final this Sunday?
>> We don't need to wait too long for 2.6.5 though. A few months would be >> appropriate. MAL> Would it be reasonable to shorten that period, if the fix for the MAL> mentioned problem gets ready for prime time earlier ? I think it would be worthwhile to prioritize all outstanding bugs which have been mentioned in the context of 2.6.[345] and run a bug day with the top priority being to fix those bugs. If that task is completed, then move onto other stuff. Once those primary bugs are tackled schedule a 2.6.5 release. Skip ___ 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
[Python-Dev] Can 3.1 still be built without complex?
I notice that WITHOUT_COMPLEX still appears in Python.h and several .c files but nowhere else in the 2.6, 2.7 or 3.1 source, most particularly not in configure or pyconfig.h.in. Are builds --without-complex still supported? Has it been tested at any time in the recent past? Skip ___ 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
Re: [Python-Dev] Can 3.1 still be built without complex?
Eric> I haven't tested it, but I still see WITHOUT_COMPLEX in trunk and py3k Eric> branches. In py3k, it's referenced in: ... Sure, but is it ever exercised? A name like WITHOUT_COMPLEX suggests that it should be flipped on/off by configure using --without-complex, but that script doesn't know about it and it's not mentioned in pyconfig.h.in, where the various --with-* flags work their magic. Skip ___ 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
Re: [Python-Dev] language summit topic: issue tracker
Brett> Another summit, another potential time to see if people want to Brett> change anything about the issue tracker. I have no idea how hard this would be to implement and won't be at the language summit to formally present the idea, but it seems to me that some integration between the issue tracker and Rietveld would be beneficial. If someone attaches a patch to an issue the current next step is essentially a code review without the benefits provided by a code review tool. I'd envision a bit of workflow like this: * A patch is attached to an issue. * The user clicks the "Create Review" button. (Maybe not all patches require review?) * This generates a review request in Rietveld with all on the nosy list invited as reviewers. (Or should this be a side effect of attaching a patch?) * The "needs review" keyword is added to the selected keywords. * A link to the review request is added as a comment to the issue so other people not on the nosy list can evaluate the patch. * If an updated diff is uploaded the review request would be updated. That might necessitate adding a "Replace Patch" button next to all uploaded patches instead of adding a new one then deleting a previous one. Skip ___ 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
Re: [Python-Dev] nonlocal keyword in 2.x?
>> So 2.7 support will for the most part be a case not of supporting >> Python versions, but Python *users*. Antoine> That's still not a good reason to backport nonlocal. The same Antoine> reasoning could be used to backport new features to the 2.6 Antoine> branch after all. No, because 2.6 is in feature freeze (bug fixes only). 2.7 is the current version of 2.x where new features are allowed to be added. Skip ___ 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
Re: [Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?
James> 2.x seems to be a fine edition of Python, why not let it keep James> going to 2.8 and beyond? Resources would be my guess. In much the same way that people move on to newer releases of Windows, Mac OSX or Linux leaving an ever-dwindling group available to support old versions, the same will be true of Python. Over time more and more of the core developers (and end users) will switch to 3.x leaving fewer and fewer people with the time or inclination to support 2.x. I think there are probably enough functional differences between 2.6 and 2.7 that releasing 2.7 makes sense. The discussion at this point should probably be what to do when 2.7 is out the door. It makes sense to me to merge the py3k branch to trunk coincident with the 2.7/3.2 releases and creation of the release27-maint and release32-maint branches. 3.3 and future versions would then be released from trunk and there would be no further 2.x releases. Skip ___ 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
Re: [Python-Dev] language summit topic: issue tracker
>> ... it seems to me that some integration between the issue tracker >> and Rietveld would be beneficial. Martin> See Martin> http://psf.upfronthosting.co.za/roundup/meta/issue247 Cool. I still haven't used Rietveld for anything, though I am getting comfortable with Review Board and like the tool support for code reviews. Skip ___ 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
Re: [Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?
Martin> And if *2.6* becomes the last of the 2.x series? With all due respect, I don't think you can make that decision now. The time to have stated 2.6 would be the end of the 2.x line was when 2.6 was released. At that point instead of opening up the trunk for changes you would have closed it off or merged the py3k branch to trunk. 2.6.0 was released over a year ago and there has been no effort to suppress bug fix or feature additions to trunk since then. If you call 2.6 "the end of 2.x" you'll have wasted a year of work on 2.7 with about a month to go before the first 2.7 alpha release. If you want to accelerate release of 2.7 (fewer alphas, compressed schedule, etc) that's fine, but I don't think you can turn back the clock at this point and decree that 2.7 is dead. Skip ___ 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
Re: [Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?
mal> I don't think users will really go for carrots. Python 2.x is mal> mature enough already and at least the users I know are really mal> happy with it (including myself). Taking that thought further back one step (or three), from http://effbot.org/tkinterbook/listbox.htm I pull this quote: In versions before Python 1.5, use string.atoi instead of int. :-) Skip ___ 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
Re: [Python-Dev] PEP 3003 - Python Language Moratorium
Guido> I've checked draft (!) PEP 3003, "Python Language Moratorium", Guido> into SVN. LGTM. Skip ___ 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
Re: [Python-Dev] PEP 3003 - Python Language Moratorium
Guido> ... it's IMO pretty mysterious if you encounter this and don't Guido> already happen to know what it means. If you require parens maybe it parses better: import (a or b or c) as mod Given that the or operator shortcuts I think that (a or b or c) terminates once a module is found isn't too hard to grasp. Skip ___ 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
[Python-Dev] raw binary data and 2to3
SpamBayes has several files which contain raw 8-bit data embedded in string literals. Before I do manual work to make them parseable by 2to3 I thought I would ask if there was either a fixer available which I'm not getting by default or if there is an opportunity to add a new fixer to 2to3. The usage is pretty straightforward. For example, a string literal might contain the bytes for a GIF image: data = "GIF89a(..." Is there a potentially automated path from where the code is today to something Python 3 (and 2to3) will like? Skip ___ 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
Re: [Python-Dev] raw binary data and 2to3
Guido> But if you're happy with only supporting 2.6, you can use b"..." and Guido> the right thing will happen. SpamBayes still supports 2.4... Thanks for the feedback. I'll update the source manually, then run 2to3. S ___ 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
Re: [Python-Dev] PyPI comments and ratings, *really*?
>> Frankly, I agree with him. As implemented, I *and others* think this >> is broken. I've taken the stance of not publishing things to PyPi >> until A> I find the time to contribute to make it better or B> It >> changes. Barry> That's distressing. For better or worse PyPI is the central Barry> repository of 3rd party packages. It should be easy, desirable, Barry> fun and socially encouraged to get your packages there. I only realized people could comment on my packages when I got the poll email from Martin. It then took me awhile to figure out how to actually see comments about my packages. https://sourceforge.net/tracker/?func=detail&aid=2897527&group_id=66150&atid=513503 At the very least I think the feature needs to be easier for package authors to use. Skip ___ 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
Re: [Python-Dev] PyPI comments and ratings, *really*?
Jesse> I don't want us to impersonate the mindless, sub-useful drivel Jesse> found in App store/YouTube/etc comments 99% of the time or the Jesse> broken "5 star ratings" systems, etc. It's too easy to game. I implemented a "5-star" system for Musi-Cal back in the day. Now, admittedly, rating musicians is a bit different than rating software, but you would probably be surprised at how much offense one musician can take when they discover that some other musician got a 4.7 rating and they only got a 4.2. :rolleyes: It did take some effort to reduce the chance that the system would be subverted. Similar to a free software site such as PyPI (and unlike a for-profit system such as the iTunes App Store), I think almost all people realized that the rating system was there to help the community and that by polluting the database they only hurt themselves. Skip ___ 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
Re: [Python-Dev] PyPI comments and ratings, *really*?
Guido> Of course, as a user, I might not trust a module that has no Guido> reviews or ratings. I suspect the vast majority of projects will never acquire ratings or reviews. Skip ___ 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
Re: [Python-Dev] Too many Python accounts (was Re: PyPI comments and ratings, *really*?)
Martin> Then I recommend that you get a google account for your email Martin> address, and register to PyPI using OpenID. I've never found OpenID at all intuitive to use. Are there instructions on pypi.python.org which detail the steps necessary to use OpenID to login? I saw the "Claim OpenID" link on my PyPI profile page. So now I have an OpenID URL. What am I supposed to do with that? If I visit that URL it downloads a small bit of XML. I've tried using my Yahoo! and Luanchpad OpenIDs for other sites in the past. I've never successfully logged into any website with them, at least not as far as I can recall. I realize that maybe this is something that just doesn't click with me (maybe I'm an OpenID Luddite), but it seems to me that OpenID needs to be a bit easier (or obvious?) to use if it's to become some sort of de facto standard login mechanism. Skip ___ 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
Re: [Python-Dev] Too many Python accounts (was Re: PyPI comments and ratings, *really*?)
Martin> That's indeed what PyPI attempts to do. At the "claim openid" Martin> place, follow the Launchpad link. It should guide you through Martin> the procedure. Well, since I use Google a lot more I'd prefer to use that. If I click the Google OpenID link I now get OpenID is already claimed Martin> Then, when you want to login, again follow the Launchpad link on Martin> the front page. That seems to work, but I'm not sure how. Doesn't seem to use cookies. The Google OpenID link leads to http://pypi.python.org/pypi?:action=login&provider=Google which contains nothing about me. I saw a pypi.python.org cookie which expires "On Quit", so I restarted Camino and verified there were no pypi.python.org cookies, then clicked the Google OpenID link. It still works. I must be missing something obvious... S ___ 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
Re: [Python-Dev] Too many Python accounts (was Re: PyPI comments and ratings, *really*?)
Martin> It's far from obvious. It's called "provider-driven identifier Martin> selection". PyPI redirects your browser to Google. Google looks Martin> at the Google cookie, and finds your identity; they also see Martin> that you have opted to automatically log into PyPI. So without Martin> further questions, they redirect you back to PyPI. PyPI finds Martin> your account, and displays a logged-in page. Thanks. Makes sense now... Skip ___ 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
Re: [Python-Dev] Sort out formatting differences in decimal and float
Sorry for being a curmudgeon, however...
>>> format(Decimal(1234), '020,g')
'0,000,000,000,001,234'
>>> format(Decimal(1234), '0=20,g')
'0001,234'
Why in the world would you ever want to insert commas as separators and not
use them consistently?
>>> format(Decimal('nan'), '020,g')
' NaN'
>>> format(Decimal('nan'), '0=20,g')
'0NaN'
Why in the world would you ever want to zero pad Nan (or Inf, for that matter)?
Stefan> The advantage of decimal is that the user has the option to
Stefan> suppress commas. The behaviour of float is slightly easier to
Stefan> implement in C.
Why? If the user asked for them why would you want to suppress (some of)
them?
Skip
___
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
Re: [Python-Dev] Sort out formatting differences in decimal and float
Mark> So should commas be inserted for any fill character at all? While I'm at it, it makes no sense to me to pad numbers with anything other than whitespace or zero. (BTW: I have never liked the new format() stuff, so I will be sticking with %-formatting as long as it exists in Python. My apologies if I don't understand some amazing generality about format(), but if you do dumb stuff like ask for comma separation of a number then ask to pad it with '*' you get what you deserve.) Mark> There's already a good way to ask for zero padding, by using the Mark> leading zero, as in '020,g'. Why would you use '0=20,g' instead? Note to the implementers: '0=20,g' has no mnemonic significance as far as I can tell. I thought it was my mail program failing to properly decode a bit of quoted printable text. Skip ___ 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
Re: [Python-Dev] bug triage
>>>>> "Nick" == Nick Coghlan writes: Nick> I'm pretty sure the bugs list is still the primary spooled Nick> notification mechanism: Nick> http://mail.python.org/mailman/listinfo/python-bugs-list Actually, there is a new-bugs-announce list: http://mail.python.org/mailman/listinfo/new-bugs-announce Skip ___ 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
[Python-Dev] Unladen cPickle speedups in 2.7 & 3.1
How much of the Unladen Swallow cPickle speedups have been incorporated into 2.7 & 3.1? I'm working on trying to develop patches for 2.4 and 2.6 (the two versions I currently care about at work - we will skip 2.5 entirely). It appears some of their speedups may have already been merged to trunk, but I'm not sure how much. If a patch to merge this to 2.7 is already under consideration I won't look at it, but I interpreted Collin Winter's response to my query on the u-s mailing list that not everything has been done yet. Thx, Skip ___ 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
Re: [Python-Dev] Unladen cPickle speedups in 2.7 & 3.1
Philip> They've documented their upstream patches here: Philip> http://code.google.com/p/unladen-swallow/wiki/UpstreamPatches Thanks. That will help immensely. Skip ___ 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
Re: [Python-Dev] Unladen cPickle speedups in 2.7 & 3.1
>>>>> "Antoine" == Antoine Pitrou writes: Antoine> pobox.com> writes: >> >> If a patch to merge this to 2.7 is already under >> consideration I won't look at it, Antoine> Why won't you look at it? :) I meant I wouldn't look at developing one. Skip ___ 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
Re: [Python-Dev] PYTHON3PATH
Lennart> What do you need to do in the PYTHONSTARTUP file?
Just reading off stuff from my own personal startup file... I use it for
stuff I want available during interactive sessions:
1. Enable true division.
2. Conditionally define "help" from back in the days when there was no
help builtin function.
3. Auto-save session (readline) history so I can easily recall commands
across sessions.
4. Add other fake builtins ("like") or override behavior of some (like
"dir") making them handier for interactive use.
5. autoload modules/symbols (pokes around in common modules from
sys.excepthook function).
Oh, and I've had no particular trouble keeping it working in Python 1, 2 or
3.
Skip
___
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
[Python-Dev] static (Modules/Setup) builds?
Just out of curiosity, is the static build stuff (use the old Modules/Setup file to build modules) exercised at all any more? Skip ___ 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
Re: [Python-Dev] PyCon Keynote
How about explaining why you're not going to give Collin a pony? Skip ___ 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
Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython
Reid> You could do a static compilation of all code objects in a .pyc to Reid> LLVM IR and compile that to a .so that you load at runtime, but it Reid> just eliminates the interpreter overhead. OTOH, it would solve the problem some people have distributing their proprietary apps as .py or .pyc files... And it could have significant performance benefits if type annotation was used (and was accurate). Skip ___ 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
Re: [Python-Dev] Summary of 2 years of Python fuzzing
Victor> Fuzzing is just one tool helping to improve the global security. Victor, Thank you, thank you, thank you. At my day job I work on automated trading systems. One key component of such tools is the safeguard subsystem which places limits on various parts of the system, the rates at which certain operations can happen or thresholds on certain value. Stuff like: * don't allow a position of more than N shares of equity ABC * don't allow more than P orders to be created in Q seconds The common wisdom within our group is that safeguards are never fully appreciated by the users of the system. Safeguards are not there to help you make more money. Quite the contrary. They are often viewed as a distraction from the prime objective: trade and make money. They are there to keep you from losing gobs of money, often in situations where you failed to anticipate some market anomaly in your new trading model. With that in mind I think of Fusil as one component of a safeguard system for Python. Fusil helps identify certain classes of anomalies in inputs to Python programs. Hopefully I will never encounter any of the corner cases you've identified with it, but if I ever do it may well save my butt. Skip ___ 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
Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython
Cesare> ... but ceval.c has a relatively stable code ... I believe you are mistaken on several counts: * The names of the functions in there have changed over time. * The suite of byte code operations have changed dramatically over the past ten years or so. * The relationship between the code in ceval.c and the Python threading model has changed. Any or all of these aspects of the virtual machine, as well I'm sure as many other things I've missed would have to be tracked by any extension module which hoped to supplant or augment its function in some way. Skip ___ 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
Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython
David> As a downstream distributor of Python, a major pain point for me David> is when Python embeds a copy of a library's source code, rather David> than linking against a system library (zlib, libffi and expat David> spring to mind): if bugs (e.g. security issues) arise in a David> library, I have to go chasing down all of the embedded copies of David> the library, rather than having dynamic linking deal with it for David> me. The Unladen Swallow developers can correct me if I'm wrong, but I believe the Subversion checkout holds a copy of LLVM strictly to speed development. If the U-S folks find and fix a bug in LLVM they can shoot the fix upstream, apply it locally, then keep moving forward without waiting for a new release of LLVM. Support exists now for building with an external LLVM, and I would expect that as Unladen Swallow moves out of active development into a more stable phase of its existence that it will probably stop embedding LLVM. Skip ___ 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
Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython
Tim> I think the performance/memory tradeoffs being discussed are fine Tim> for the long-running / server apps (20mb on a 8Gb machine is Tim> negligable) At work our apps' memory footprints are dominated by the Boost-wrapped C++ libraries we use. 100MB VM usage at run-time is pretty much the starting point. It just goes up from there. We'd probably not notice an extra 20MB if it was shared. Skip ___ 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
Re: [Python-Dev] Improved Traceback Module
pje> If you look for a local variable in each frame containing a format pje> string, let's say __trace__, you could apply that format string to pje> a locals+globals dictionary for the frame, in place of dumping all pje> the locals by default I commented on the blog post before noticing all the replies here. I'll embellish that suggestion by suggesting that instance attributes can be as valuable when debugging instance methods. Perhaps __trace_self__ (or similar) could be fed from self.__dict__ if it exists? Skip ___ 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
Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython
Cesare> I think that wpython as a proof-of-concept have done its work, Cesare> showing its potentials. If you haven't alreayd is there any chance you can run the Unladen Swallow performance test suite and post the results? The code is separate from U-S and should work with wpython: http://unladen-swallow.googlecode.com/svn/tests -- Skip Montanaro - s...@pobox.com - http://www.smontanaro.net/ ___ 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
Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython
Cesare> ... (you can find the wpython 1.0 final here Cesare> <http://code.google.com/p/wpython2/downloads/list>). I tried downloading it. Something about wpython10.7z and wpython10_fix.7z. What's a 7z file? What tool on my Mac will unpack that? Can I build and run wpython on my Mac or is it Windows only? Thx, Skip ___ 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
Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython
Cesare> You can find 7-Zip tools here Cesare> <http://www.7-zip.org/download.html>. Thanks. Found a tool named 7za in MacPorts which I was able to install. One strong suggestion for future releases: Please put a top-level directory in your archives. It is annoying to expect that only to have an archive expand into the current directory without creating a directory of its own. I've been burned often enough that I always check before expanding source archives from new (to me) sources, so no harm, no foul in this case. Skip ___ 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
Re: [Python-Dev] Forking and Multithreading - enemy brothers
>> I guess spawnl semantic (i.e, like win32's CreateProcess()) can't >> become the default multiprocessing behaviour... Nick> It would also make it much easier to write cross-platform Nick> multiprocessing code (by always using the non-forking semantics Nick> even on fork-capable systems) I don't understand. On Unix-y systems isn't spawn* layered on top of fork/exec? One thing that nobody seems to have pointed out is that the subprocess module was originally written as a multi-processing module with an API very similar to the threading module. That is, it was intended to be used as an alternative to threading. I would find it odd to use both together, and in particular, to create threads first, then fork. If you were going to combine both threading and multiprocessing it seems much more logical to me to fork first (coarse-grained subdivision) then create threads (finer grained threads of control) in those processes. Skip ___ 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
Re: [Python-Dev] Forking and Multithreading - enemy brothers
Tres> Some applications may seem to work when violating this rule, but Tres> their developers are doomed to hair loss over time. Then for us bald guys it should be okay, right? ;-) Skip ___ 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
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
Maybe an alternate sprint idea would be to incorporate dateutil into the Python core: http://labix.org/python-dateutil Skip ___ 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
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
Maybe an alternate sprint idea would be to incorporate dateutil into the Python core: http://labix.org/python-dateutil Whoops... (just waking up - still need that first cup of coffee) While incorporating dateutil into the core would be nice (in my opinion at least), I was really thinking of pytz: http://pytz.sourceforge.net/ Skip ___ 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
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
Lennart> The timezone database is updated several times per year. You Lennart> can *not* include it in the standard library. My guess is the data are updated several times per year, not the code. Can they not be separated? Skip ___ 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
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
Lennart> I would like if we could look into making a timezone module Lennart> that works on Python 2.5 to 3.2 that uses system data... 2.5, 2.6 and 3.1 are completely off the radar screen at this point. The best you could hope for is that someone backports whatever is created for 2.7 or 3.2 and distributes it outside the normal distribution channel (say, as a patch on PyPI). Skip ___ 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
Re: [Python-Dev] some notes from the first part of the lang summit
Guido> Maybe the best thing is to make optparse *silently* deprecated, Guido> with a big hint at the top of its documentation telling new users Guido> to use argparse instead, but otherwise leaving it in indefinitely Guido> for the benefit of the many existing users. Would a 2to3 fixer be possible? S ___ 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
[Python-Dev] Another version of Python
Some of you have probably already seen this, but in case you haven't: http://www.staringispolite.com/likepython/ :-) Skip ___ 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
