REG: Fix read_parquet from file-like objects
State: closed

- [x] xref #34467
- [x] tests added / passed
- [x] passes `black pandas`
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [x] whatsnew entry - waiting on https://github.com/pandas-dev/pandas/pull/34481

Use arrow parquet.read_table opposed to ParquetDataset


Labels:
name: Regression
description: Functionality that used to work in a prior pandas version
name: IO Parquet
description: parquet, feather

Comments:
> whatsnew entry - waiting on #34481

I merged that PR
The original version (before https://github.com/pandas-dev/pandas/pull/33632) used `get_filepath_or_buffer`, which eg also enables to read from urls. Do you know if that is tested? 
> The original version (before #33632) used `get_filepath_or_buffer`, which eg also enables to read from urls. Do you know if that is tested?

Agree - previously untested and I missed this in #33632 - apologies for that. I've added a test case for this. @jorisvandenbossche 
Hello @alimcmaster1! Thanks for updating this PR. We checked the lines you've touched for [PEP 8](https://www.python.org/dev/peps/pep-0008) issues, and found:





There are currently no PEP 8 issues detected in this Pull Request. Cheers! :beers: 

##### Comment last updated at 2020-06-12 18:15:00 UTC
> Looks good to me.
> The url still needs to be changed before merging?
> 
> Do you think this should be safe to use for 1.0.5? (as the other option is to revert the original PR for 1.0.5, and keep this for master only)
> 
> cc @simonjayhawkins

I was planning on updating the URL post merge. Other option is I can open a separate PR with just .parquet file so it exists on master. I think should be fine for 1.0.5 - any additional test cases you can think of would be helpful. 

I would propose to keep this for 1.1 (and we reverted to original patch in the 1.0.x branch for 1.0.5). @alimcmaster1 you can remove the whatsnew note then? (we still need to add a similar line to the v1.0.5.txt, but that should be done in a separate PR)
> I would propose to keep this for 1.1 (and we reverted to original patch in the 1.0.x branch for 1.0.5). @alimcmaster1 you can remove the whatsnew note then? (we still need to add a similar line to the v1.0.5.txt, but that should be done in a separate PR)

Yes makes sense - I’ll do this tomorrow.
this now doesn't close the issue as that's actually marked for 1.0.5? 

The plan is to patch that separately right?
IIUC, all that needs to be done is move the release note to 1.1.0.rst. I'll do that now.
Actually, I'm sufficintly confused about what the appropriate whatsnew to describe the changes from 1.0.5 to 1.1 is, so I'll leave that to you @alimcmaster1.
In this PR, the whatsnew only needs to be simply removed (this is fixing a regression compared to master, so doesn't need a whatsnew). Describing what's changed in 1.0.5, that's for a separate PR that gets backported.

Will do that now
I also updated the URL to point to the master branch, so this is going to fail anyway here, thus merging directly
Thanks @alimcmaster1 !
Thanks for fixing up @jorisvandenbossche - apologies I didn’t get to this. I’ll add the 1.0.5 whatsnew note you mentioned