Re: [Python-Dev] what to do if you don't want your module in Debian
On Tue, Apr 27, 2010 at 9:15 AM, David Malcolm wrote: > On Mon, 2010-04-26 at 21:19 +0200, Piotr Ożarowski wrote: >> Many Python module developers do not want their work to be distributed >> by Debian (and probably by other Linux distributions), here's a list of > Thanks! Not just Debian: I can confirm, from bitter experience, that > your list is also highly applicable to Fedora and RHEL... Honestly, it's enough to publish your python application/library/module to pypi (at least this is true for my work). Re-packing some xyz Linux distribution's package mangement system just seems useless and a waste of time (with exceptions ofc). --James ___ 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
On Sat, Jun 19, 2010 at 10:42 PM, Antoine Pitrou wrote: > I should point out that I am in no way responsible for the migration. > I think Dirkjan and Brett said they would tackle this after the 2.7 > release. But they'd better answer by themselves :) I'm willing to help out if needed. Can't hurt to have another set of hands :) I'm sure there are others in the Mercurial/Python community that would be willing to help too! cheers james ___ 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] Drive suffix
On Thu, Aug 5, 2010 at 1:10 AM, Guido van Rossum wrote: > It's Windows specific syntax and always a colon. Use > os.path.splitdrive() to parse it. I don't think there's a need to add > a named constant for it (you're the first to ask, in my memory). HI Guido, I'm not a windows user or developer, but I concur. When I was reading this post I kept thinking to myself that Windows is one of the only Operating Systems with a File system that reuiqres this [A-Z]:\ syntax. All sensible POSIX systems I know and File Systems all mount various other media on "mount points". *shrug* --James -- -- James Mills -- -- "Problems are solved by method" ___ 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] (Not) delaying the 3.2 release
On Thu, Sep 16, 2010 at 8:09 AM, Antoine Pitrou wrote: > I don't see what we gain by holding up the 3.2 release. Some writing a > Web application will need third-party modules anyway, so downloading > wsgi3ref shouldn't be too painful. I agree with you. Further, is wsgiref actually heavily used by web developers and or web framework developers at all ? I would tend to think that web developers might be more interested in using some of the larger more popular web frameworks such as: TurboGears, Django, Pylons, Cherrypy, etc. i don't think a Python 3.2 release should be held up because of wsgiref. cheers James -- -- James Mills -- -- "Problems are solved by method" ___ 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 444 aka "Web3" (was Re: how to decide on a Python 3 design for wsgiref)
On Thu, Sep 16, 2010 at 9:06 AM, Chris McDonough wrote: > Comments and competing specs would be useful. Can I post comments here ? :) I have one initial comment (at first glance). I'm not sure I quite like the idea of changing the keys from wsgi to web3 for the simple reason that you will already have to port your application to python3 (bytes vs. str) anyway. Changing the keys is just more unnecessary work (although one could just use a search/replace). My 2c (or pence) cheers james -- -- James Mills -- -- "Problems are solved by method" ___ 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] (Not) delaying the 3.2 release
On Thu, Sep 16, 2010 at 9:31 AM, Jesse Noller wrote: > My goal (personally) is to make sure python 3.2 is perfectly good for use in > web applications, and is therefore a much more interesting porting target for > web projects/libraries and frameworks. Python 3 is already quite well done and very usable by web frameworks (at least my tiny one). (It's just my opinion of course). I think the biggest problem is the uptake of Python 3 itself and the general attitude towards Python 3 as a whole. That's what's stopping me from focusing on and even maintaining a Python 3 branch for my project(s). cheers James -- -- James Mills -- -- "Problems are solved by method" ___ 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-checkins] r88395 - python/branches/py3k/Lib/asyncore.py
On Mon, Feb 14, 2011 at 8:11 AM, wrote: > On 08:06 pm, greg.ew...@canterbury.ac.nz wrote: >> >> exar...@twistedmatrix.com wrote: >>> >>> On 10:46 pm, greg.ew...@canterbury.ac.nz wrote: >>>>> >>>>> On Sun, 13 Feb 2011 11:19:06 +1300 >>>>> Greg Ewing wrote: >>>> >>>> I was thinking of something lighter-weight than that. >>> >>> Twisted Core >> >> I just had a look at the docs for Twisted Core, and it lists >> 10 sub-modules. The only one that really looks "core" to me >> is twisted.internet. Drilling into that reveals another >> 39 public sub-sub-modules and 10 private ones. >> >> Sorry, but you'll have to chop it back quite a bit more than >> that before it's focused enough to be a stlib module, I think. > > Excluding stuff is not hard, seriously. It's not hard to see that wxPython > integration doesn't belong in the stdlib. There are more useful aspects of > the task to discuss. I don't mean to but in here and I may have no business doing so... But what about circuits.core ? cheers James -- -- James Mills -- -- "Problems are solved by method" ___ 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-checkins] r88395 - python/branches/py3k/Lib/asyncore.py
On Mon, Feb 14, 2011 at 8:36 AM, Michael Foord wrote: > Well, what about it? The virtue of twisted is that even if we haven't all > used it, we've all heard of it. That speaks volumes about its penetration > into the python world. Just a mere suggestion. The fact that this discussion exists means that Twisted may end up being in the std. lib in the end because no-one can come up with a better? solution that meets "all" requirements. In any case, there are other alternatives. I realize we're not discussing them but it's nice to know what is and can be included in the std. lib, etc. I'll just follow and keep quiet now :) cheers James -- -- James Mills -- -- "Problems are solved by method" ___ 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-checkins] r88395 - python/branches/py3k/Lib/asyncore.py
On Tue, Feb 15, 2011 at 10:45 AM, wrote: > As far as the difficulties of "finding" the good ideas in Twisted goes, > there are several people familiar with Twisted already contributing to this > thread. Between us all, I'm sure we can dig out the insidiously buried > secrets. As I mentioned before, I've also started a PEP myself to lay bare > the mysteries. I may try working on it some more, since there seems to be > some interest. So far in this discussion (I'm not really contributing very much) I agree with several things: a) We should have a PEP outlining the proposed new "async" lib. b) It should be general purpose enough to use without Twisted (for example) I like the idea of having an "async" core in the std. lib that takes care of cross-platform polling of I/O descriptors, notifications and timers. cheers James -- -- James Mills -- -- "Problems are solved by method" ___ 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-checkins] r88395 - python/branches/py3k/Lib/asyncore.py
On Tue, Feb 15, 2011 at 11:09 AM, Daniel Stutzbach wrote: > If we go with something based on or inspired by Twisted, that solves some > problems, but creates others. Will users be able to later migrate to using > Twisted proper? Will the standard library module and Twisted go out of > sync? What happens if a user tries to use both the standard library module > and Twisted? Or any other async / application framework. --JamesMills ___ 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] pydoc for named tuples is missing methods
On Mon, Mar 14, 2011 at 12:41 PM, Tim Lesher wrote:
> [I mentioned this to Raymond Hettinger after his PyCon talk, and I
> promised a bug and hopefully a patch. I don't see an obvious solution,
> though, so I'll ask here first.]
>
> Because named tuple prefixes a single underscore to its added method
> names (_asdict, _replace, and _make), those methods' docstrings are
> omitted from pydoc:
>
>>>> Point=collections.namedtuple('Point', 'x y')
>>>> help(Point)
> Help on class Point in module __main__:
> [output omitted; it excludes _asdict, _replace, and _make]
>
> pydoc's rules for name inclusion are in pydoc.visiblename():
>
> * If the name is in the hidden list, omit it
> * If the name looks like a __special_method__, include it
> * If the there is an "all" specified, then include it if it appears in all
> * Otherwise, include it if it doesn't begin with an underscore
>
> There doesn't seem to be an obvious way to get around these rules for
> named tuples... am I overlooking something?
Works for me. Python 3.2 on 32bit Linux.
cheers
James
--
-- James Mills
--
-- "Problems are solved by method"
___
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] pydoc for named tuples is missing methods
On Mon, Mar 14, 2011 at 12:57 PM, James Mills wrote: >> [output omitted; it excludes _asdict, _replace, and _make] Sorry I missed this bit :) > Works for me. Python 3.2 on 32bit Linux. Scrap that :) cheers James -- -- James Mills -- -- "Problems are solved by method" ___ 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] pydoc for named tuples is missing methods
On Tue, Mar 15, 2011 at 9:48 AM, R. David Murray wrote: > But directly calling a __xxx__ method in Python is a very > unusual thing to do. It would be extremely odd to have that > be the expected way to call a method on a class. Can't namedtuple be improved to support the named fields _and_ have as_dict() and replace() without leading underscores ? cheers James -- -- James Mills -- -- "Problems are solved by method" ___ 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] pydoc for named tuples is missing methods
On Tue, Mar 15, 2011 at 11:50 AM, Terry Reedy wrote: >> How would that work if you had a field named "replace"? I think >> Raymond's current design is as good as it's going to get. > > 'as_dict' is an unlikely fieldname. 're_place' is too, but that just shift > the '_' from '_replace'. No gain. I might prefer _asdict to _as_dict, but > not enough to change. Probably a stupid idea (sorry) but one could just make asdict() and replace() public methods with the caveat that developers not use those as field names. cheers James -- -- James Mills -- -- "Problems are solved by method" ___ 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] Not-a-Number
On Fri, Apr 29, 2011 at 11:11 AM, Ben Finney wrote: > Would it make sense for ‘NaN’ to be another instance of ‘NoneType’? This is fine IHMO as I (personally) find myself doing things like: if x is None: ... cheers James -- -- James Mills -- -- "Problems are solved by method" ___ 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] RELEASED Python 3.0rc3
On Sat, Nov 22, 2008 at 1:06 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On behalf of the Python development team and the Python community, I am > happy to announce the third and last planned release candidate for Python > 3.0. Whoohoo! :) Great works guys! --JamesMills -- -- -- "Problems are solved by method" ___ 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] multiprocessing vs. distributed processing
I've noticed over the past few weeks lots of questions asked about multi-processing (including myself). For those of you new to multi-processing, perhaps this thread may help you. Some things I want to start off with to point out are: "multiprocessing will not always help you get things done faster." "be aware of I/O bound applications vs. CPU bound" "multiple CPUs (cores) can compute multiple concurrent expressions - not read 2 files concurrently" "in some cases, you may be after distributed processing rather than multi or parallel processing" cheers James -- -- "Problems are solved by method" ___ 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
