Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Daniel Holmes
    @jaitaiwan
    I don’t even know why it would do that
    Rick Hanlon II
    @rickhanlonii
    and i don't think that it can be decoded. let me try
    i think it's a urllib bug
    Daniel Holmes
    @jaitaiwan
    What versions does it exist in?
    Rick Hanlon II
    @rickhanlonii
    https://hg.python.org/cpython/file/3.4/Lib/urllib/parse.py#l810
    on that line elt equals [b'FOO', b'BAR']
    which, to string is: '[b\\'FOO\\', b\\'BAR\\']'
    hence the extra b's
    Daniel Holmes
    @jaitaiwan
    print(str([b'FOO',b'BAR'])) equals [b'FOO', b'BAR']
    Shouldn’t it be ['FOO', 'BAR']
    oh wait no
    Rick Hanlon II
    @rickhanlonii
    not in python 3
    Daniel Holmes
    @jaitaiwan
    the utf vs ascii stuff has really confuzzled me haha
    Rick Hanlon II
    @rickhanlonii
    same lol
    i think we remove the multi key and ship it
    Daniel Holmes
    @jaitaiwan
    Saweet
    Which means we will have 2.0 ready before I’ve even finished 1.9 readme changes haha
    Rick Hanlon II
    @rickhanlonii
    lol
    so it goes
    i should investigate why this test passes
    https://github.com/rickhanlonii/python-oauth2/blob/f1dfde33b9dd5862ceac200d83715bdc1e478d9f/tests/test_oauth.py#L714-L738
    Daniel Holmes
    @jaitaiwan
    It’s not even valid...
    The url should be:
    multi[]=par1, multi[]=par2
    At least that’s my understanding
    Rick Hanlon II
    @rickhanlonii
    yeah
    that's what i thought too
    seems like we can ship and deal with issue as they arise
    Daniel Holmes
    @jaitaiwan
    I also remember someone complaining about getting all the values from the url when a variable is specified multiple times
    Rick Hanlon II
    @rickhanlonii
    yeah, that's probably it
    Daniel Holmes
    @jaitaiwan
    We should at least change it so it fits URL spec
    Rick Hanlon II
    @rickhanlonii
    any preference on which fork we go with for py3?
    we're not breaking any backwards compatibility so i'd be inclined to open an issue and fix in a minor release
    if only because it's been years waiting for a py3 release
    if you're keen on getting it in though, i'm not fussed
    Daniel Holmes
    @jaitaiwan
    Fair enough… We could do a dual release… So release py3 with 1.9.1 and also 1.10
    Ugh
    I mean 1.8.x 1.9
    Rick Hanlon II
    @rickhanlonii
    yeah, that sounds like the move
    Daniel Holmes
    @jaitaiwan
    Ok did some research and both /foo/bar?foo[]=bar&foo[]=baz&foo[]=qux and /foo/bar?foo=bar&foo=baz&foo=qux
    So we probably need to open a request to allow specifying which version to use as it’s web-server dependant
    Rick Hanlon II
    @rickhanlonii
    yeah, agreed
    Daniel Holmes
    @jaitaiwan
    Cool. So to-do:
    (1) Remove multi test (2) Open issue to cover a new test which is more accurate (3) modify readme and move examples to wiki (4) Release 1.9 and 1.8.x with Python compatibility.
    Rick Hanlon II
    @rickhanlonii
    yep, i can handle 1 and 2
    Daniel Holmes
    @jaitaiwan
    Saweet!
    Dude we’re bossing it with this OSP
    haha
    Rick Hanlon II
    @rickhanlonii
    :two_men_holding_hands:
    Daniel Holmes
    @jaitaiwan
    :shipit:
    Guilherme Bazilio
    @gbazilio
    anyone using the lib as a provider?