[Migrating the discussion from https://bugs.python.org/issue44768.]
PEP 20 says:
> There should be one-- and preferably only one --obvious way to do it.
There are two ways to create a simple named type to store data:
collections.namedtuple and dataclasses.dataclass. I propose deprecating
named
I was writing some code the other day, and it needed a quick-and-dirty data
structure definition for a set of related variables. I looked back at other
code to try be consistent, and found that I used dataclasses in some parts and
namedtuples in others. Both seemed the right thing to do at the t
It's not actually that, although that's a good point you are making. I found
myself using both of them not because one is more useful in certain cases and
the other in others in small and niche ways. Both of the times I just used the
latest one that came to mind. The fact that two different clas
I'm with you on the backwards-compatibility front. Changing Python fast and for
no particular reason incurs a big cost. Is the reason good enough to justify
removing a chunk of the interface? Good question.
To your dict argument: if there was a native Pythonic way to make a frozen
list, what wo
I like this idea! It's true that deprecating the namedtuple we lose important
semantics of order - however, if its use as a weaker dataclass is explicitly
discouraged in the documentation, then much of the problem (i.e., people that
want to have a simple data object use two incompatible things d
MyPy has plans to support heterogenous tuple representation, it turns out. It
is tracked here: https://github.com/python/mypy/issues/5152 - albeit not very
actively.
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email t
Hi Folks,
We have released PythonQL, a query language extension to Python (we have
extended Python’s comprehensions with a full-fledged query language,
drawing from the useful features of SQL, XQuery and JSONiq). Take a look at the
project here: http://www.pythonql.org and lets us know what yo
lumn-expressions>
> - https://github.com/cloudera/ibis/blob/master/ibis/sql/alchemy.py
> <https://github.com/cloudera/ibis/blob/master/ibis/sql/alchemy.py>
>
> On Tuesday, November 1, 2016, Pavel Velikhov <mailto:[email protected]>> wrote:
> Hi Folks,
>
>
suppose.
> On 1 Nov 2016, at 21:17, David Mertz wrote:
>
> How do you see this as different from Blaze
> (http://blaze.readthedocs.io/en/latest/index.html
> <http://blaze.readthedocs.io/en/latest/index.html>)?
> A
>
>
> On Nov 1, 2016 1:34 AM, &quo
make nested queries easier to write and a few minor bells and
whistles.
>
>> On Tuesday, November 1, 2016 at 2:03:44 PM UTC-5, Pavel Velikhov wrote:
>> Hi David!
>>
>> I haven’t used blaze, but its looks quite similar to pandas, at least
>> conceptually.
Hi folks!
We started a project to extend Python with a full-blown query language about
a year ago. The project is call PythonQL, the links are given below in the
references section. We have implemented what is kind of an alpha version now,
and gained some experience and insights about why and
Hi Terry!
Thanks for your feedback, I have a couple comments below.
> On 24 Mar 2017, at 20:50, Terry Reedy wrote:
>
> On 3/24/2017 11:10 AM, Pavel Velikhov wrote:
>> Hi folks!
>>
>> We started a project to extend Python with a full-blown query language
>>
> On 25 Mar 2017, at 02:19, Greg Ewing wrote:
>
> Terry Reedy wrote:
>> PQL expressions should be quoted and passed to the dsl processor, as done
>> with SQL and other DSLs.
>
> But embedding one language as quoted strings inside another
> is a horrible way to program.
>
> I really like the i
gt; Side note : I might not have understood what you were doing, so if I'm
> off-topic, tell me !
>
> -Brice
>
Thanks for the feedback! This is very useful.
>
> Le 24/03/17 à 16:10, Pavel Velikhov a écrit :
>> Hi folks!
>>
>> We started a project t
Hi Paul!
> On 25 March 2017 at 11:24, Pavel Velikhov wrote:
>> No, the current solution is temporary because we just don’t have the
>> manpower to
>> implement the full thing: a real system that will rewrite parts of PythonQL
>> queries and
>> ship them to und
> On 25 Mar 2017, at 15:51, Gerald Britton wrote:
>
> On 25 March 2017 at 11:24, Pavel Velikhov <http://gmail.com/>> wrote:
> > No, the current solution is temporary because we just don’t have the
> > manpower to
> > implement the full thing: a real system
t;http://dask.pydata.org/en/latest/dataframe.html>
>
> So I think your burden is even higher than showing the usefulness of
> PythonQL. You have to show why it's worth adding new syntax to do somewhat
> LESS than is available in very widely used 3rd party tools that avoid new
&
Hi Mark,
> On 25 Mar 2017, at 19:54, Mark E. Haase wrote:
>
> Hi Pavel,
>
> This is a really impressive body of work. I had looked at this project in the
> past but it is great to get back up to speed and see all the progress made.
>
> I use Python + databases a
Hi Michel!
> On 25 Mar 2017, at 22:43, Michel Desmoulin wrote:
>
> Hello,
>
> I've been following PythonQL with interest. I like the clever hack using
> Python encoding. It's definitely not something I would recommend to do
> for an inclusion in Python as it hijack the Python encoding method,
>
Terry,
> On 26 Mar 2017, at 07:23, Terry Reedy wrote:
>
> On 3/25/2017 11:40 AM, Kyle Lahnakoski wrote:
>>
>> Pavel,
>>
>> I like PythonQL. I perform a lot of data transformation, and often find
>> Python's list comprehensions too limiting;
Hi Nick,
Thanks for such a detailed response!
> On 25 Mar 2017, at 19:40, Nick Coghlan wrote:
>
> First off, I think PythonQL (and PonyORM before it) is a very
> interesting piece of technology. However, I think some of the answers
> so far suggest we may need to discuss a couple of meta-iss
Hi Nick!
> On 26 Mar 2017, at 18:02, Nick Coghlan wrote:
>
> On 26 March 2017 at 21:40, Pavel Velikhov wrote:
>> On 25 Mar 2017, at 19:40, Nick Coghlan wrote:
>>> Right, the target audience here *isn't* folks who already know how to
>>> construct their
even have this :
>
> query = PQL(
> Select("x", "sum_y"),
> Where("x", "y", lambda x, y: x % 2 == 0 and y % 2 != 0 and x > y),
> Where("sum_y", lambda sum_y: sum_y % 2 != 0)
> GroupBy("x"),
>
23 matches
Mail list logo
