Re: [Python-Dev] [Python-ideas] PEP
On 2012-03-08, at 22:08 , Mark Janssen wrote: > I just noticed something in Guido's example. Something gives me a strange > feeling that using a variable as a key doesn't smell right. Presumably > Python just hashes the variable's id, or uses the id itself as the key Python calls ``hash`` on the object and uses the result. > , but > I wonder if anyone's noticed any problems with this, and whether the hash > collision problems could be solved by removing this?? No. Not that it makes sense, people could ask for object hashes on their own and end up with the same result. > Does anyone even > use this functionality -- of a *variable* (not a string) as a dict key? What you're asking does not make sense, the dict key is not the name but whatever object is bound to the name. And yes I've used non-string objects as names before: tuples, frozensets, integers, my own objects, … ___ 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] Enhancing the shutil module
On 18 Jan 2010, at 14:57 , Michael Foord wrote: > > On 18/01/2010 13:46, Doug Hellmann wrote: >> >> On Jan 18, 2010, at 8:34 AM, Masklinn wrote: >> >>> On 18 Jan 2010, at 13:40 , Nick Coghlan wrote: >>>> >>>> Tarek Ziadé wrote: >>>>> There's one remaining external call for "zip" done if the zip module >>>>> is not found, but I am happy to remove it and throw an exception if >>>>> it's not found, and keep the external "zip" call on Distutils side, so >>>>> shutil stays 100% stdlib-powered. >>>> >>>> +1 for that approach. These changes all sound like nice additions to >>>> shutil, and hooray for every module that gets adopted by an active >>>> maintainer :) >>> >>> Isn't it a bit weird to include that to shutil though? shutil advertises >>> itself as "a number of high-level operations on files and collections of >>> files." > > Well - isn't what's being proposed "a number of high-level operations on > files and collections of files." ? > Well no those are high-level operations on a very restricted set of file types (archives). >>> and from what I understood it was a bunch of shell-type utility functions > > like tar and zip? :-) > Tar and zip have a module each at this time, so they're considered pretty big. I don't think anybody would consider "mv" big enough to give it a module on its own. >>> Wouldn't it make more sense to put those "archive utils" functions/objects >>> in a new module separate from shutil, dealing specifically with >>> cross-archive APIs and linked from the current archive-specific modules >>> (essentially, just take the current archive_util, move it to the toplevel >>> of the stdlib and maybe rename it)? It would also make the module much >>> easier to find when searching through the module listing, I think. >> >> +1 >> > > Proliferation of modules is itself a bad thing though. Yes, but so is the loss of focus of a module. I hate using that argument, but I fear this would be a step on a slippery slope of making shutil a monster-bag of anything that has to do with inodes, no matter how tenuous or removed the connection is. Plus having this as a toplevel module/package would open the window to moving all archive-related modules within it (in the py4 window), à la xml package without having to move itself. ___ 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] Enhancing the shutil module
On 18 Jan 2010, at 13:40 , Nick Coghlan wrote: > > Tarek Ziadé wrote: >> There's one remaining external call for "zip" done if the zip module >> is not found, but I am happy to remove it and throw an exception if >> it's not found, and keep the external "zip" call on Distutils side, so >> shutil stays 100% stdlib-powered. > > +1 for that approach. These changes all sound like nice additions to > shutil, and hooray for every module that gets adopted by an active > maintainer :) Isn't it a bit weird to include that to shutil though? shutil advertises itself as "a number of high-level operations on files and collections of files." and from what I understood it was a bunch of shell-type utility functions to easily copy, move or remove files and directories (that's pretty much all there is in it at this time). Wouldn't it make more sense to put those "archive utils" functions/objects in a new module separate from shutil, dealing specifically with cross-archive APIs and linked from the current archive-specific modules (essentially, just take the current archive_util, move it to the toplevel of the stdlib and maybe rename it)? It would also make the module much easier to find when searching through the module listing, I think. ___ 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] standard libraries don't behave like standard 'libraries'
On 13 Nov 2009, at 11:36 , Anand Balachandran Pillai wrote: > I think the recent postings on "CPAN for Python" in this list also stems > from similar thoughts. No. The CPAN for Python messages (in and out of the list) are about third-party packages and a better way to manage (and a better experience of installing) those. Think Ruby, it has a significant stdlib (though not as extensive as Python's), but it also has gems (and the `gem` CLI util). Or Haskell, which also has a significant stdlib (GHC does anyway) but also has cabal and cabal-install. ___ 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*?
On 13 Nov 2009, at 00:37 , Martin v. Löwis wrote: >> Users (which includes e.g. language users) tend to be lazy, rather than >> stupid. > Then they likely won't comment on PyPI. To do so, they have to setup an > account (which most don't have). They can't post comments without an > account. Fair point ___ 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*?
On 13 Nov 2009, at 00:15 , Antoine Pitrou wrote: > Masklinn masklinn.net> writes: >> >> On 13 Nov 2009, at 00:00 , Antoine Pitrou wrote: >>> >>> Then why not simply add a sentence or two before the comment form warning > that >>> the comment system is not meant to ask for help, support or debugging about > the >>> package? >> Because users don't read warnings. > I don't like assuming users are idiots. You don't have to. It's about expediency and care (or lack thereof) rather than idiocy. User(*) wants a solution, user finds place where he could ask, user asks. Users (which includes e.g. language users) tend to be lazy, rather than stupid. >> The warning will therefore be promptly ignored, and then the >> aforementioned user will start ripping on the package because he didn't get >> help following his comment. > And then it's easy to point out that he was wrong if there was a warning in > the > first place. And then user will probably ask why you're not answering the question since you're here anyway, or might go as far as telling you that if you're not going to help you might as well not answer. *: not every user, but I believe a significant minority at least. ___ 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*?
On 13 Nov 2009, at 00:00 , Antoine Pitrou wrote: > > Then why not simply add a sentence or two before the comment form warning that > the comment system is not meant to ask for help, support or debugging about > the > package? Because users don't read warnings. The warning will therefore be promptly ignored, and then the aforementioned user will start ripping on the package because he didn't get help following his comment. ___ 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*?
On 12 Nov 2009, at 23:44 , James Y Knight wrote: > On Nov 12, 2009, at 5:23 PM, Masklinn wrote: >> On 12 Nov 2009, at 22:53 , James Y Knight wrote: >>> On Nov 12, 2009, at 4:11 PM, Ben Finney wrote: >>>> I think Jesse's point (or, if he's not willing to claim it, my point) is >>>> that, compared to the mandatory comment system, it makes much *more* >>>> sense to have a mandatory field for “URL to the BTS for this project”. >>> >>> One might look at the "competition" for inspiration. Looking at CPAN. >>> There's no "comments" feature >> There is, on search.cpan.org. See http://search.cpan.org/~petdance/ack/ for >> instance, the link leads to http://cpanratings.perl.org/ (a pretty >> interesting example of the "distributed" nature of cpan in fact). > > Ah, I see. I totally managed to miss that...I guess that's an interesting > example of a bad web ui. :) I'm not sure it's so bad, it's just that it's at the root of the "cpan package" rather than in the POD (just click on "BDB-mysql" in the breadcrumb trail, landing at http://search.cpan.org/~capttofu/DBD-mysql/). Interestingly, the link to cpanratings from BDB-mysql is broken and yields a 404, even though its CPAN page lists 5 reviews and a score of ~3.5. ___ 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*?
On 12 Nov 2009, at 22:53 , James Y Knight wrote: > On Nov 12, 2009, at 4:11 PM, Ben Finney wrote: >> I think Jesse's point (or, if he's not willing to claim it, my point) is >> that, compared to the mandatory comment system, it makes much *more* >> sense to have a mandatory field for “URL to the BTS for this project”. > > One might look at the "competition" for inspiration. Looking at CPAN. There's > no "comments" feature There is, on search.cpan.org. See http://search.cpan.org/~petdance/ack/ for instance, the link leads to http://cpanratings.perl.org/ (a pretty interesting example of the "distributed" nature of cpan in fact). ___ 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*?
On 12 Nov 2009, at 17:31 , Jesse Noller wrote:
>
> But before we even did those; why not have mandatory links for entries
> to bug trackers, mailing lists, source repositories, etc? I'm saying
> saying this doesn't seem well thought out, and the current
> implementation is broken by design. Of course, as I said earlier;
> since I don't have time to patch it; I'll simply just not participate.
I think having links to those is a very good idea and more important
than a comment/notation system. They shouldn't be mandatory though, not
every library has a mailing list, or even a (public anyway) bug tracker.
Giving users and easy way to contact the author would be a must as well
("package index owner" and "package index maintainer" should link to
the users's profiles, and users should be able to setup contact
informations e.g. a mail address or a website). See how search.cpan
does it, the information is worth a lot to users. Currently, finding
how to send feedback to a package owner usually requires wading through
the description text itself, which in some cases (e.g. distribute)
amounts to pages of document.
On 12 Nov 2009, at 17:31 , Jesse Noller wrote:
> I don't want us to impersonate the mindless, sub-useful drivel found
> in App store/YouTube/etc comments 99% of the time or the broken "5
> star ratings" systems, etc. It's too easy to game.
I think I read a paper on that subject a short time ago (but can't
seem to find it right now), basically saying 5-star systems weren't
very useful, a simple +1/0/-1 was just as good (if not better) and
0/+1 worked as well.
___
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] Top-posting on this list
On 11 Oct 2009, at 13:36 , Tarek Ziadé wrote: On Sun, Oct 11, 2009 at 1:26 PM, Ben Finney > wrote: "Stephen J. Turnbull" writes: Trimming can be a PITA if you're using a crummy MUA How so? It merely requires the ability to navigate up and down by lines, and to select and delete text. I've used some very crummy MUAs, but the ability to trim quoted text has never been absent or difficult. Are there MUAs so crummy that this is a PITA, yet still used by any significant portion of email users? You just can't do it on some mobile device mail clients. For instance Gmail's client on Android. It will just top-post and quote the whole mail for you AFAIK. I'll add the iPhone pre 3.0 Mail (also holds for the Touch): while trimming was possible, it was done using the delete key and character per character (jumping to word per word after a few seconds) because there was no selection. This made trimming long mails a fairly long-winded task already, but things were even worse due to the lack of undo: not stopping soon enough (and deleting part of the text you wanted to quote) meant you had to either re-type it manually or restart the whole operation from the start. This has thankfully been fixed (with the addition of a pretty good selection mechanism and an undo). Another iPhone mail "feature", (which hasn't been fixed and is actually just as broken in the desktop version of Mail) is that Mail is hardcoded to top-post: it's not possible to make the insertion point default to bottom the quote, it's always above it with a bunch of white-spaces for the message. Not much of an issue, but it still makes top-posting lower friction than bottom-posting or trimming. ___ 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] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
On 8 Oct 2009, at 19:22 , David Cournapeau wrote: This is not true - stow solves the problem in a more general way (in the sense that it is not restricted to python), at least on platforms which support softlink. I was, of course, talking about "pure" Python solutions (but I should indeed have qualified my statement thus), in the general cases there are several solutions to handle that including but not limited to stow you already mentioned, BSD jails or full-blown virtual machines. ___ 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] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
On 8 Oct 2009, at 18:17 , Toshio Kuratomi wrote: This is not at all how I use virtualenv. For me virtualenv is a sandbox so that I don't have to become root whenever I need to install a Python package for testing purposes This is needing to install multiple versions and use the newly installed version for testing. No it's not. It's keeping the python package *being tested* out of the system's or user's site-package because it's potentially unstable or unneeded. It provides a trivial way of *removing* the package to get rid of it: delete the virtualenv. No trace anywhere that the package was ever installed, no impact on the system (apart from the potential side-effects of executing the system). The issue here isn't "multiple installed packages", it will more than likely be the only version of itself: note that it's a package being tested, not an *upgrade* being tested. The issues solved are: * not having to become root (solved by PEP 370 if it ever lands) * minimizing as much as possible the impact of testing the package on the system (not solved by any other solution) and to allow me to hop between sets of installed Python packages while developing on multiple Python projects. This is the ability to install multiple versions and specify different versions for different projects you're working on. No, this is the ability to not needlessly clutter site-packages, keep them clean, tight, focused; and the ability to keep a project's environment (such as its dependencies) clear and repeatable. Nowhere was it indicated that multiple versions were involved. Both of those *might* imply issues of multiple versions concurrently installed on the system, and virtualenv would incidentally solve these issues, but these issues are *not* the core of either use case. They're at best peripheral and potential ___ 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] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
On 8 Oct 2009, at 18:17 , Toshio Kuratomi wrote: This is not at all how I use virtualenv. For me virtualenv is a sandbox so that I don't have to become root whenever I need to install a Python package for testing purposes This is needing to install multiple versions and use the newly installed version for testing. No it's not. It's keeping the python package *being tested* out of the system's or user's site-package because it's potentially unstable or unneeded. It provides a trivial way of *removing* the package to get rid of it: delete the virtualenv. No trace anywhere that the package was ever installed, no impact on the system (apart from the potential side-effects of executing the system). The issue here isn't "multiple installed packages", it will more than likely be the only version of itself: note that it's a package being tested, not an *upgrade* being tested. The issues solved are: * not having to become root (solved by PEP 370 if it ever lands) * minimizing as much as possible the impact of testing the package on the system (not solved by any other solution) and to allow me to hop between sets of installed Python packages while developing on multiple Python projects. This is the ability to install multiple versions and specify different versions for different projects you're working on. No, this is the ability to not needlessly clutter site-packages, keep them clean, tight, focused; and the ability to keep a project's environment (such as its dependencies) clear and repeatable. Nowhere was it indicated that multiple versions were involved. Both of those *might* imply issues of multiple versions concurrently installed on the system, and virtualenv would incidentally solve these issues, but these issues are *not* the core of either use case. They're at best peripheral and potential. ___ 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
