4 ms·

Guido can release python 7, and still minority will use it, since many libs (https://python3wos.appspot.com/ https://python3wos.appspot.com/) are not ported to

by eddd 13y ago

Guido can release python 7, and still minority will use it, since many libs (https://python3wos.appspot.com/ https://python3wos.appspot.com/) are not ported to python 3.

makmanalp 13y ago
That list sure is turning greener and greener every day. It's getting harder to use that as an excuse. I think my next project, I'll start using py3. The main big ones I see are boto (has a partial 3k fork that isn't official yet) and mysql-python (looks pretty dead, shame). Quite a few others like Gevent and supervisor, for example, have py3k ports nearly done, and mostly await merging.
- rodelrod 13y ago
  MysqlDB was holding me back from Python3, but that problem was settled with Oracle releasing a Python connector for MySQL [1] that works for both Python 2.x and 3.x. It's a solid and very complete library and it's DB-API compliant, so that migrating from MysqlDB can be pratically seamless. [1] https://dev.mysql.com/downloads/connector/python/ https://dev.mysql.com/downloads/connector/python/
  - makmanalp 13y ago
    I've looked into that, have you seen any performance regression due to the fact that it's pure python?
    - rodelrod 13y ago
      That's a very good point. I tend to drop down quickly from the ORM to do SQL level optimization on hot spots, and that is the case of the applications where I have used this connector. Also, we are talking about entreprise applications with relatively low number of requests, albeit a lot of them resource intensive. In this context, the performance of the connector is not critical. I can tell you that it is good enough that I didn't have to change my usual architecture choices for performance reasons. Your case may be different. edit: changed grammar for clarity
      - makmanalp 13y ago
        This is good to hear. I'm leaning more towards using postgres on my next project, but for the sake of science, let me think it out a bit more: Your average interactive webapp is reasonably query-heavy, some of which is alleviated by reasonable caching. The performance of the connector comes into play when someone hits an uncached page which requires tens of queries. This matters the most when it drastically affects load time. It's really a shitty experience when a user comes to a page, waits more than a second for the page to load. I do find, though, that a large portion of my query overhead comes from round trip time to the db server, and not intermediate processing. So I figure for low to medium traffic sites with reasonable caching (and cache priming when needed), this probably won't be a bit hit, like you say. There is of course the interesting benefit that if you're using a JIT implementation like pypy, then everything within a pure python db adapter is up for auto-optimization. This is interesting because it could effectively provide something close to application-specific hand optimization of the connector, which tends to be a pain in the ass that not many people would bother with.
- tragic 13y ago
  It seems like in the time I've been using python (about 18 months, really) the community has really stepped up the pressure to switch to 3.x. The vast majority of what I use day-to-day has now been ported (just noticed Paramiko support has been merged to master two days ago[1], so Fabric'll follow rapidly after that), and every time I see a new book come out it demands Python 3. I will try to be a good boy and use it going forward (I already find it more useful for CSV and other file I/O type tasks thanks to the unicode support, but am reliant on mysql for some routine drudgery as well). [1] https://github.com/paramiko/paramiko/pull/276 https://github.com/paramiko/paramiko/pull/276
- mildtrepidation 13y ago
  "Excuse" seems like a loaded word to use here. It's a valid reason when your dependencies don't work or haven't been thoroughly tested in Python 3.

by eddd 13y ago

Guido can release python 7, and still minority will use it, since many libs (https://python3wos.appspot.com/ https://python3wos.appspot.com/) are not ported to python 3.

makmanalp 13y ago

That list sure is turning greener and greener every day. It's getting harder to use that as an excuse. I think my next project, I'll start using py3. The main big ones I see are boto (has a partial 3k fork that isn't official yet) and mysql-python (looks pretty dead, shame). Quite a few others like Gevent and supervisor, for example, have py3k ports nearly done, and mostly await merging.

rodelrod 13y ago
MysqlDB was holding me back from Python3, but that problem was settled with Oracle releasing a Python connector for MySQL [1] that works for both Python 2.x and 3.x. It's a solid and very complete library and it's DB-API compliant, so that migrating from MysqlDB can be pratically seamless. [1] https://dev.mysql.com/downloads/connector/python/ https://dev.mysql.com/downloads/connector/python/
- makmanalp 13y ago
  I've looked into that, have you seen any performance regression due to the fact that it's pure python?
  - rodelrod 13y ago
    That's a very good point. I tend to drop down quickly from the ORM to do SQL level optimization on hot spots, and that is the case of the applications where I have used this connector. Also, we are talking about entreprise applications with relatively low number of requests, albeit a lot of them resource intensive. In this context, the performance of the connector is not critical. I can tell you that it is good enough that I didn't have to change my usual architecture choices for performance reasons. Your case may be different. edit: changed grammar for clarity
    - makmanalp 13y ago
      This is good to hear. I'm leaning more towards using postgres on my next project, but for the sake of science, let me think it out a bit more: Your average interactive webapp is reasonably query-heavy, some of which is alleviated by reasonable caching. The performance of the connector comes into play when someone hits an uncached page which requires tens of queries. This matters the most when it drastically affects load time. It's really a shitty experience when a user comes to a page, waits more than a second for the page to load. I do find, though, that a large portion of my query overhead comes from round trip time to the db server, and not intermediate processing. So I figure for low to medium traffic sites with reasonable caching (and cache priming when needed), this probably won't be a bit hit, like you say. There is of course the interesting benefit that if you're using a JIT implementation like pypy, then everything within a pure python db adapter is up for auto-optimization. This is interesting because it could effectively provide something close to application-specific hand optimization of the connector, which tends to be a pain in the ass that not many people would bother with.
tragic 13y ago
It seems like in the time I've been using python (about 18 months, really) the community has really stepped up the pressure to switch to 3.x. The vast majority of what I use day-to-day has now been ported (just noticed Paramiko support has been merged to master two days ago[1], so Fabric'll follow rapidly after that), and every time I see a new book come out it demands Python 3. I will try to be a good boy and use it going forward (I already find it more useful for CSV and other file I/O type tasks thanks to the unicode support, but am reliant on mysql for some routine drudgery as well). [1] https://github.com/paramiko/paramiko/pull/276 https://github.com/paramiko/paramiko/pull/276
mildtrepidation 13y ago
"Excuse" seems like a loaded word to use here. It's a valid reason when your dependencies don't work or haven't been thoroughly tested in Python 3.