Log file Viewer
#pypa-dev logs for Monday the 4th of June, 2018
[13:59:32] <ronny> ncoghlan: just a quick question - wil python 3.6. move docstrings into the module again or will it stay as is
[14:00:13] <ncoghlan> ronny: not clear yet, but my own predication is that we'll make DocString a new AST node type
[14:02:08] <sumanah> I was briefly wondering if you were making an ARM reference, like, chips and stuff
[14:02:30] <ronny> ncoghlan: another question - whats necessary to get a strucutrally consistent version of itemgetter, unpacking a tuple will cause different results dependong on whether its 1 element or more elements
[14:04:28] <techalchemy> ncoghlan: I am planning to cut a release today(?) with a bunch of fixes, no idea if I will get anything to handle the multiple inline `-e <thing>` case in this one
[14:05:12] <techalchemy> release is dependent upon what looks like an out of order non-deterministic resolution failure probably related to forking out suprocesses to do installations before we actually make a virtualenv
[14:05:18] <ncoghlan> techalchemy: no worries - I don't think that's urgent, since it was more the behaviour inherited from `pip` that surprised me
[14:05:28] <ronny> techalchemy: its stopping me from doing one pure python optimization in pluggy since unpacking one element to itemgetter makes it return elements and n elements returns tuples
[14:06:11] <ronny> (the optimization gets bad yield when there is need for a single element workaround)
[14:15:39] <ronny> ncoghlan: anyway - for both attrgetter and itemgetter there dont seem to be from_iterable versions that always return a tuple - what would be the process to get that fixed?
[14:16:51] <ncoghlan> ronny: tricky since they're kind of oddball additions to the operator module anyway
[14:17:28] <ncoghlan> it was one thing when they just replicated what the syntax can do (appropriate for the operator module), something else entirely when they went beyond it
[14:18:02] <ncoghlan> so trying to fix it highlights the fact that it was a mistake to extend those APIs with non-operator functionality in the first place
[14:19:07] <ronny> ncoghlan: well, extending them per se wasnt wrong, but it wasnt done in a thought out manner
[14:26:58] <ronny> ncoghlan: its getting more and more regular that i have to approach python as a language whose stdlib cant be used nicely :/
[14:27:15] <ncoghlan> ronny: something I'd personally like to see is opreator.getitems() and opreator.getattrs(), which could then be combined with functools.partialmethod
[14:31:17] <ncoghlan> ronny: nah, not for the operator module - python-ideas discussion, then (hopefully) a tracker issue and PR
[14:32:57] <ncoghlan> the fact the status quo has a weird special case for length 1 tuples, whereas partialmethod(getitems, *keys) would consistently return a tuple should help make the case
[14:34:04] <techalchemy> ncoghlan: doesn't everything behave strangely with one-length tuples though
[14:35:19] <techalchemy> like if I go through the legacy codebase at work I can find tons of examples of people doing: `tuple = (thing,)` because `tuple = (thing)` was functionally the same as `tuple = thing`
[14:35:42] <ronny> ncoghlan: for context - what i do is take a set of full kwargs and call a hook that implements a subset of them with them applied as positional arguments
[14:36:06] <ncoghlan> @techalchemy That's different - that's the fact that it's "," that makes a tuple literal, not parentheses
[14:37:11] <ronny> techalchemy: hooks arent methods per se, and the nromal methodcaller doesnt do safe calls last i checked
[14:38:09] <ncoghlan> @ronny If you're currently using itemgetter, then the replacement would be partialmethod so the first late bound positional arg gets used as the first arg to the underlying function.
[14:40:06] <techalchemy> ncoghlan: the number of bugs the "," literal for tuples has caused people is probably quite large, and I think it's mostly because of the large # of blog posts describing how calling the 'tuple' function or the 'list' function is inefficient or whatever
[16:15:20] <sumanah> btw, folks who like to use Etherpads, I have started using https://pad.sfconservancy.org/
[17:44:04] <Pharyngeal> Is there a way to be added to the CI system for Pipenv? I want to see the errors, but I get a 404.
[18:32:45] <Pharyngeal> techalchemy: Also, as part of that PR I need to adjust the deps resolver, but it looks like resolve.py is called directly instead of used as a module
[18:33:27] <Pharyngeal> Should I add an additional command line arg to resolve.py to accomodate the mirrors?
[18:39:19] <techalchemy> Pharyngeal: I rebuilt your failing build, anytime appveyor passes and buildkite fails you should assume it means you're fine
[18:42:36] <Pharyngeal> techalchemy: That's what I figured, I just wasn't 100% sure. Thanks! For the resolver.py, that's the plan. The issue is, it's not being used as a module, so I can't just add an extra arg to a function
[18:55:17] <sixninetynine> hey are there any pip maintainers about? my PR is in limbo and I'd love some input/direction (#5404)
[19:04:00] <sixninetynine> sokay, I don't want to come off as pesky or pushy. I know everyone's time is a limited and valuable resource :)
[19:05:30] <sumanah> sixninetynine: so I have a few suggestions for things that *might* help. I am not a pip maintainer and I may be wrong
[19:05:30] <techalchemy> Pharyngeal: should be pretty straightforward that just takes args and drops them into a function call
[19:06:12] <sumanah> sixninetynine: 1 is to look at other pip issues/PRs and see if you can answer any questions
[19:06:23] <Pharyngeal> techalchemy: Right. The issue is, it only expects switches right now, so I'll have to make some modifications to accept parameters
[19:07:56] <sumanah> sixninetynine: and my other suggestion is: this is enough of a policy implementation decision that you could send a heads-up to https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ and https://mail.python.org/mailman/listinfo/wheel-builders to ask for feedback
[19:09:41] <Pharyngeal> techalchemy: Will anyone ever call resolver.py directly? Things will be easier if I can do --key=value rather than --key value
[19:10:02] <sixninetynine> sumanah: unfortunately no, though I believe we met (albeit briefly) at the packaging open space at PyCon
[19:13:24] <techalchemy> Pharyngeal: people do, for debugging purposes, and we call it directly in utils.py '
[19:15:40] <Pharyngeal> techalchemy: Right. What I'm saying is, there'd have to be some additional logic to handle something that isn't a switch, yet isn't a package item
[19:16:19] <Pharyngeal> Something like pypi_mirror = sys.argv.pop(sys.argv.index('--pypi-mirror') + 1)
[19:17:43] <Pharyngeal> techalchemy: I need to add support there so all of the calls from venv_resolve_deps work
[19:18:30] <Pharyngeal> are you suggesting I have venv_resolve_deps set its new pypi_mirror parameter as an environment variable before resolver.py is called?
[19:18:55] <techalchemy> I'm considering the alternatives, I haven't thought about the implications much
[19:19:41] <Pharyngeal> techalchemy: any operation that calls do_lock needs to accept a pypi_mirror param
[19:21:47] <Pharyngeal> techalchemy: That would be an option if it weren't for the execution method of resolver.py, which is not used as a module
[19:21:48] <techalchemy> then you can set it as an environment variable temporarily when you call 'venv_resolve_deps' and pick it up again
[19:22:53] <techalchemy> but you can also just set the flag as an environment variable the same way we do with packages for now
[19:24:00] <Pharyngeal> techalchemy: Also, unrelated, maybe I'm just missing something entirely, but why the .joins here? https://ncry.pt/p/gfOn#8B5ghvMJQOURFsibrj0-4sOJKT50bRExqBrILpUMrdE
[19:24:09] <techalchemy> @Pharyngeal: https://github.com/pypa/pipenv/blob/master/pipenv/utils.py#L344
[19:30:31] <techalchemy> Pharyngeal: also, seriously, thanks for you effort on this, it is tremendously appreciated