#beets

11 passing tests in py3.. ..

I talk when I work, on IRC, too...

i'm glad that most of the places where we use map we can actually use iters

it was only two places where it was broken on py3 iters

i rewrote/reformatted the wikipage on the py3 transition

anybody here work with tox?

jrobeson: Sorry for disappearing yet again, but now I'm back.

yay

For map and such, I agree that either six or future is the right thing to do.

vs from future_builtins ?

Yes, because of the reason you highlighted—unless we want to use future_builtins as a stopgap for now.

at least for map.. so far most places work just fine in py2 and 3 !

(Possibly behind an `except ImportError`, I guess.)

there were only 2 places where it failed

Yeah! That's the nice thing.

i fixed the two cases that failed the tets in python 3

And we can use list(map(...)) for most cases, which will force the same behavior on both.

Oh, awesome

so we don't really have to do anything for those

i'd prefer to avoid list(map()) where we can. because keeping the iters is best

🎉

Yes, absolutely

not sure if you saw this, but this py2 stuff is kinda hard for me ;(

i didn't start writing my own python scripts until py3 (even though I've been coding since 2001)

Right, since you're a Python 3 native! Which is awesome

but still, i'm not very good at that either

Thanks for struggling through it—it's great to have fresh eyes look at this stuff

i mostly write/wrote in php

modern php

although i've done a few things in erlang, lua, and ruby (and now rust)

oh.. and very bad C

web is my specialty more so than this kinda thing

I've *really* been enjoying the small amount of Rust I've been doing lately, FWIW

sampsyo, there is one thing that really really really really really confused me.. lemme see if i can find it again

while i'm finding it, look at this https://codecov.io/gh/beetbox/beets .. do you see a warning about the bot here?

Hmm, no…

oh it's gone for me now too

it was there, must have been a transient error

https://github.com/beetbox/beets/commit/9c41c39... PLEASE EXPLAIN!

Oh right, I remember you asking about that and I didn't immediately know

oh.. that musta been fallout from using import unicode_literals

Yeah, that must be the explanation

i think that commit should just straight up be reverted

Yes, exactly—this is a perfect case of needing "native strings"

(i.e., bytes on 2, unicode on 3)

i think reverting it would work

me too

can you do it?

Sure.

so, in python3 .. bytes cannot be used as keyword args

Makes sense.

is there any paritcular reason out_type in mediafile.py really needs to be b'out_type' ?

there are a lot of weird places where b is used .. that i don't understand why

That's weird

like os.platform() .. the output isn't bytes

I'm guessing that was another sad unicode_literals casualty

Here's my guess:

this is the biggest problem with the port

Python 2, of course, uses bytes for kwargs. Therefore, `kwargs.get(u'foo')` wouldn't work—and it was the default with unicode_literals.

So to patch things up and "make it work", somebody made it b''.

But that, of course, only works on Python 2.

If only we'd never done the whole unicode_literals thing…

atm.. the base commit on my local py3 branch is just a naive replace all unicode() with str() .. and that's been enough to get to the point where we get passing tests (beyond the b'out_type')

Cool!

i titled it convert all unicode() to str() .. pick up pieces later

plus all the previous commits that were acceptable to py3

err py2

well unicode_literals were needed.. until they decided to allow u''!

Perfect. If that's the bulk of the work, then using `from some_compat_lib import string_type` should work for the transition.

Right. IMO requiring 3.3 seems fine to me, though.

i don't think that's the bulk of the work to pass all the tests. that's just to get to the point where anything loads at all

Aha, great.

currently beets loads too many things before the tests happen

the lazy config really needs to be wrapped in a function

atm it's instantiated right when you import beets

It shouldn't be… the idea is that it doesn't do anything until you actually need it.

then there's something else calling it too soon

Yeah, probably so.

That lazy config loading thing is kind of a hack, though—I'd love to replace it with something more sensible.

that was the hardest thing for awhile

just to get to the point where the tests even run

It's kind of a trade-off between the convenience of being able to say `config['setting']` anywhere, without threading through an explicit object, and the predictability of passing through the configuration.

i'd much rather pass through the configuration, unless it really is that unwieldy. but i'm not trying to mess with that

not until i get a better handle on the codebase

Yeah, it's probably out of scope for the py3 transition.

so what's the deal with all the tests failing on windows?

i mean appveyor

it sounds like beets should right now run on windows based on the docs, but does it?

Things mostly work fine on Windows, but there are some problems with the test harnesses.

i'm not sure if we can really trust this py3 conversion until that is solved :(

One of the big ones has to do with sqlite being shared between threads, which is apparently not allowed on Windows?

well the most of the first errors have to do with module has no attribute edit or something like that

is it possible to run beets without any threads?

just block on everything

it'll be slow, but at least it will work.

what windows doesn't like, is multiple things acting on the same file

You can turn off threading via the configuration—worth a try.

well the module edit thing is probably something else (unless you can see why otherwise)

in regards to pathlib.. it would make things easier, but with the backport being in bad shape.. i'm trying to punt on it until we drop py2.. unless it becomes untenable

uggh.. this bytes thing is gonna be a real killer :(

so, i'm wondering why the py3 port hasn't been the main focus of the project for awhile?

i guess that's what i get for spending so much time with py3

i personally find py2 not really worth dealing with at all

as a user of a py2 script. it's not so bad

but as a coder :(

so, on to more important questions

On that last thing: the explanation is pretty standard

six or future

It's just that we all have a finite amount of attention to bring, so we can't do everything. Not an exciting explanation, but it's the truth!

i'm only doing it because I just don't want to do anything else on beets until it's py3

Good motivation. :)

untitaker, didn't wanna six (or anything else) as a dependency until py3 works already

i didn't get a chance to ask him why he said that.. and i certainly don't understand the reasoning

i'm trying to do this in such a way that if i get too busy.. the codebase will still be one step closer to py3 .. without all the work stuck in a bitrotten branch

I don't have strong feelings about that, except that we add a dependency with plenty of warning for packagers.

how does that happen?

wouln't it just come to their attention when they try to package it?

obviously it' be in the changelog

Mainly, add a dependency right after another release (and announce it on the mailing list) so they can prepare

(and test)

so, is there some python decoration thing for deprecated functions/methods ?

there are 4 deprecated functikons in confit, however the codebase was never actually adapted

i don't think things should be allowed to be deprecated unless all callers in the same codebase are dapted

adapted*

There's a DeprecationWarning class in warnings; we could try that.

there's lots of places where we need to import config.StrSeq

confit*

Right.

so what's the rules in import *

Avoid it except for special cases—it makes it hard to see where a name came from.

so.. back to the other question.. six or future ..

i was originally leaning towards future as it looks more useful.. however the bug tracker doesn't fill me with confidence

and there was definitely an important fix (regarding their new bytes type) that isn't in any release yet

I really couldn't tell from looking why one would be better than the other

One supports more versions, but they're versions we don't need

Good point about bugs though!

the library we choose for this is of the utmost importance

it affects too many things fur os not to be concerned

Indeed, I just honestly can't tell which is better

future is definitely better to me.. if the bug tracker wasn't so concerning

whichever one we pick.. i really don't think it will stick around too long though