celery multi celery.exceptions.TimeoutError: The operation timed out

[iMath]

Asked 3 days ago at 
https://stackoverflow.com/questions/63951696/celery-multi-celery-exceptions-timeouterror-the-operation-timed-out

But nobody helped yet, anyone ?
-- 
https://mail.python.org/mailman/listinfo/python-list

Pythonic style

[Stavros Macrakis]

I'm trying to improve my Python style.

Consider a simple function which returns the first element of an iterable
if it has exactly one element, and throws an exception otherwise. It should
work even if the iterable doesn't terminate. I've written this function in
multiple ways, all of which feel a bit clumsy.

I'd be interested to hear thoughts on which of these solutions is most
Pythonic in style. And of course if there is a more elegant way to solve
this, I'm all ears! I'm probably missing something obvious!

Thanks,

  -s

def firsta(iterable):
it = iter(iterable)
try:
val = next(it)
except StopIteration:
raise ValueError("first1: arg not exactly 1 long")
try:
next(it)
except StopIteration:
return val
raise ValueError("first1: arg not exactly 1 long")

def firstb(iterable):
it = iter(iterable)
try:
val = next(it)
except StopIteration:
raise ValueError("first1: arg not exactly 1 long")
try:
next(it)
except StopIteration:
return val
else:
raise ValueError("first1: arg not exactly 1 long")

def firstc(iterable):
it = iter(iterable)
try:
val = next(it)
except StopIteration:
raise ValueError("first1: arg not exactly 1 long")
try:
next(it)
raise ValueError("first1: arg not exactly 1 long")
except StopIteration:
return val

def firstd(iterable):
it = iter(iterable)
try:
val = next(it)
except StopIteration:
raise ValueError("first1: arg not exactly 1 long")
for i in it:
raise ValueError("first1: arg not exactly 1 long")
return val

def firste(iterable):
it = iter(iterable)
try:
good = False
val = next(it)
good = True
val = next(it)
good = False
raise StopIteration   # or raise ValueError
except StopIteration:
if good:
return val
else:
raise ValueError("first1: arg not exactly 1 long")

def firstf(iterable):
n = -1
for n,i in enumerate(iterable):
if n>0:
raise ValueError("first1: arg not exactly 1 long")
if n==0:
return i
else:
raise ValueError("first1: arg not exactly 1 long")
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Issues with pip in Python 3.8.3

[Hylton]

Hello,

 �

I have subscribed to the Python list.

The user name (which was optional) I entered as hsb3852, not my real name.

Does this matter?

 �

My question is below…

 �

Best regards,

Hylton

 �

From: Hylton  
Sent: Monday, September 21, 2020 6:41 AM
To: python-list@python.org
Subject: Issues with pip in Python 3.8.3

 �

Hello,

 �

I’m quite new to Python (but not new to programming), and I’ve encountered 
problems with pip which I have been unable to solve.

 �

When I tried to update pip using “python.exe -m pip install --upgrade pip” (I 
tried to install another package -unsuccessfully, which informed me there was a 
new version of pip), which failed with the following error:

 �

ERROR: Exception:

Traceback (most recent call last):

 � File 
"C:\Users\user\AppData\Roaming\Python\Python38\site-packages\pip\_internal\cli\base_command.py",
 line 216, in _main

 � � � status = self.run(options, args)

 � File 
"C:\Users\user\AppData\Roaming\Python\Python38\site-packages\pip\_internal\cli\req_command.py",
 line 182, in wrapper

 � � � return func(self, options, args)

 � File 
"C:\Users\user\AppData\Roaming\Python\Python38\site-packages\pip\_internal\commands\install.py",
 line 412, in run

 � � � installed = install_given_reqs(

 � File 
"C:\Users\user\AppData\Roaming\Python\Python38\site-packages\pip\_internal\req\__init__.py",
 line 82, in install_given_reqs

 � � � requirement.install(

 � File 
"C:\Users\user\AppData\Roaming\Python\Python38\site-packages\pip\_internal\req\req_install.py",
 line 813, in install

 � � � install_wheel(

 � File 
"C:\Users\user\AppData\Roaming\Python\Python38\site-packages\pip\_internal\operations\install\wheel.py",
 line 852, in install_wheel

 � � � _install_wheel(

 � File 
"C:\Users\user\AppData\Roaming\Python\Python38\site-packages\pip\_internal\operations\install\wheel.py",
 line 762, in _install_wheel

 � � � generated_console_scripts = maker.make_multiple(scripts_to_generate)

 � File 
"C:\Users\user\AppData\Roaming\Python\Python38\site-packages\pip\_vendor\distlib\scripts.py",
 line 418, in make_multiple

 � �  �filenames.extend(self.make(specification, options))

 � File 
"C:\Users\user\AppData\Roaming\Python\Python38\site-packages\pip\_internal\operations\install\wheel.py",
 line 498, in make

 � � � return super(PipScriptMaker, self).make(specification, options)

 � File 
"C:\Users\user\AppData\Roaming\Python\Python38\site-packages\pip\_vendor\distlib\scripts.py",
 line 407, in make

 � � � self._make_script(entry, filenames, options=options)

 � File 
"C:\Users\user\AppData\Roaming\Python\Python38\site-packages\pip\_vendor\distlib\scripts.py",
 line 307, in _make_script

 � � � self._write_script(scriptnames, shebang, script, filenames, ext)

 � File 
"C:\Users\user\AppData\Roaming\Python\Python38\site-packages\pip\_vendor\distlib\scripts.py",
 line 242, in _write_script

 � � � launcher = self._get_launcher('t')

 � File 
"C:\Users\user\AppData\Roaming\Python\Python38\site-packages\pip\_vendor\distlib\scripts.py",
 line 386, in _get_launcher

 � � � raise ValueError(msg)

ValueError: Unable to find resource t64.exe in package pip._vendor.distlib

WARNING: You are using pip version 20.2.2; however, version 20.2.3 is available.

You should consider upgrading via the 'C:\Program Files\Python38\python.exe -m 
pip install --upgrade pip' command.

 �

C:\Program Files\Python38>

 �

I checked that the file t64.exe does exist in the location (path) listed 
(C:\Users\user\AppData\Roaming\Python\Python38\site-packages\pip\_vendor\distlib\scripts).

This path is included in the PATH environment variable.

 �

Why is this upgrade failing? How do I fix it?

 �

I get this same error when I try to install other packages too.

 �

The package I tried to install was numPy.

 �

I also need to install cv2 and OpenCV, but my searches for them in PyPA 
returned dozens, if not hundreds of results. Can you perhaps indicate which 
versions I need to install on my Windows 10 PC?

 �

Please help as soon as possible by return email.

 �

Many thanks!

Hylton

 �

 �

 �

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: celery multi celery.exceptions.TimeoutError: The operation timed out

[Menno Holscher]

Op 21-09-2020 om 12:14 schreef iMath:

Asked 3 days ago at 
https://stackoverflow.com/questions/63951696/celery-multi-celery-exceptions-timeouterror-the-operation-timed-out

But nobody helped yet, anyone ?

Did you see 
https://stackoverflow.com/questions/9769496/celery-received-unregistered-task-of-type-run-example 
?


The error says "Received unregistered task of type 'proj.tasks.add'", so 
it looks very much like your registry is not correct/complete.


Vriendelijke groeten/Kind regards,

Menno Hölscher


--
https://mail.python.org/mailman/listinfo/python-list

Re: Puzzling difference between lists and tuples

[Serhiy Storchaka]

18.09.20 03:55, Chris Angelico пише:
> On Fri, Sep 18, 2020 at 10:53 AM Grant Edwards
>  wrote:
>> Yea, the syntax for tuple literals has always been a bit of an ugly
>> spot in Python.  If ASCII had only had one more set of open/close
>> brackets...
> 
> ... then I'd prefer them to be used for sets, actually. I think the
> set/dict collision is more weird than the tuple/grouping one.
> 
> Now, if only ASCII had *two* more sets of open/close brackets...

Then I would use them for sets and frozensets.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Puzzling difference between lists and tuples

[Chris Angelico]

On Mon, Sep 21, 2020 at 10:14 PM Serhiy Storchaka  wrote:
>
> 18.09.20 03:55, Chris Angelico пише:
> > On Fri, Sep 18, 2020 at 10:53 AM Grant Edwards
> >  wrote:
> >> Yea, the syntax for tuple literals has always been a bit of an ugly
> >> spot in Python.  If ASCII had only had one more set of open/close
> >> brackets...
> >
> > ... then I'd prefer them to be used for sets, actually. I think the
> > set/dict collision is more weird than the tuple/grouping one.
> >
> > Now, if only ASCII had *two* more sets of open/close brackets...
>
> Then I would use them for sets and frozensets.
>

Ahem. AMONG the needs for additional types of brackets are such
diverse types as.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pythonic style

[Léo El Amri via Python-list]

On 21/09/2020 00:34, Stavros Macrakis wrote:
> I'm trying to improve my Python style.
> 
> Consider a simple function which returns the first element of an iterable
> if it has exactly one element, and throws an exception otherwise. It should
> work even if the iterable doesn't terminate. I've written this function in
> multiple ways, all of which feel a bit clumsy.
> 
> I'd be interested to hear thoughts on which of these solutions is most
> Pythonic in style. And of course if there is a more elegant way to solve
> this, I'm all ears! I'm probably missing something obvious!

Hello Stavros,

As there is no formal definition nor consensus on what is Pythonic and
what isn't, this reply will be very subjective.



My opinion on your code suggestions is the following:

> 1 def firstf(iterable):
> 2 n = -1
> 3 for n,i in enumerate(iterable):
> 4 if n>0:
> 5 raise ValueError("first1: arg not exactly 1 long")
> 6 if n==0:
> 7 return i
> 8 else:
> 9 raise ValueError("first1: arg not exactly 1 long")

firstf isn't Pythonic:

1. We are checking twice for the same thing at line 4 (n>0)
   and 6 (n==0).

2. We are using enumarate(), from which we ignore the second element
   it yields in its tuple

> 1 def firstd(iterable):
> 2 it = iter(iterable)
> 3 try:
> 4 val = next(it)
> 5 except StopIteration:
> 6 raise ValueError("first1: arg not exactly 1 long")
> 7 for i in it:
> 8 raise ValueError("first1: arg not exactly 1 long")
> 9 return val

firstd isn't Pythonic. While the usage of a for statement in place of a
try..except saves two lines, it is at the expense of showing a clear
intent: When I see a for statement, I expect a "complex" operation on
the iterable items (which we are ignoring here).

>  1 def firsta(iterable):
>  2 it = iter(iterable)
>  3 try:
>  4 val = next(it)
>  5 except StopIteration:
>  6 raise ValueError("first1: arg not exactly 1 long")
>  7 try:
>  8 next(it)
>  9 except StopIteration:
> 10 return val
> 11 raise ValueError("first1: arg not exactly 1 long")

>  1 def firstb(iterable):
>  2 it = iter(iterable)
>  3 try:
>  4 val = next(it)
>  5 except StopIteration:
>  6 raise ValueError("first1: arg not exactly 1 long")
>  7 try:
>  8 next(it)
>  9 except StopIteration:
> 10 return val
> 11 else:
> 12 raise ValueError("first1: arg not exactly 1 long")

>  1 def firstc(iterable):
>  2 it = iter(iterable)
>  3 try:
>  4 val = next(it)
>  5 except StopIteration:
>  6 raise ValueError("first1: arg not exactly 1 long")
>  7 try:
>  8 next(it)
>  9 raise ValueError("first1: arg not exactly 1 long")
> 10 except StopIteration:
> 11 return val

firsta, firstb and firstc are equally Pythonic. I have a preference for
firsta, which is more concise and have a better "reading flow".

>  1 def firste(iterable):
>  2 it = iter(iterable)
>  3 try:
>  4 good = False
>  5 val = next(it)
>  6 good = True
>  7 val = next(it)
>  8 good = False
>  9 raise StopIteration   # or raise ValueError
> 10 except StopIteration:
> 11 if good:
> 12 return val
> 13 else:
> 14 raise ValueError("first1: arg not exactly 1 long")

firste might be Pythonic although it's very "C-ish". I can grasp the
intent and there is no repetition. I wouldn't write the assignation at
line 7, though.



Mixing firsta and firste would make something more Pythonic:

def firstg(iterable):
it = iter(iterable)
try:
val = next(it)
try:
next(it)
except StopIteration:
return val
except StopIteration:
pass
raise ValueError("first: arg not exactly 1 long")

1. The code isn't repetitive (The "raise ValueError" is written
   only once)

2. The intent is a bit harder to grasp than for firsta or firste, but
   the code is shorter than firste

3. The try..catch nesting is considered a bad practice, but the code
   here is simple enough so it shouldn't trigger a strong aversion
   reading it



- Léo
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pythonic style

[Tim Chase]

On 2020-09-20 18:34, Stavros Macrakis wrote:
> Consider a simple function which returns the first element of an
> iterable if it has exactly one element, and throws an exception
> otherwise. It should work even if the iterable doesn't terminate.
> I've written this function in multiple ways, all of which feel a
> bit clumsy.
> 
> I'd be interested to hear thoughts on which of these solutions is
> most Pythonic in style. And of course if there is a more elegant
> way to solve this, I'm all ears! I'm probably missing something
> obvious!

You can use tuple unpacking assignment and Python will take care of
the rest for you:

  >>> x, = tuple() # no elements
  Traceback (most recent call last):
File "", line 1, in 
  ValueError: not enough values to unpack (expected 1, got 0)
  >>> x, = (1, )  # one element
  >>> x, = itertools.repeat("hello") # 2 to infinite elements
  Traceback (most recent call last):
File "", line 1, in 
  ValueError: too many values to unpack (expected 1)

so you can do

  def fn(iterable):
x, = iterable
return x

The trailing comma can be hard to spot, so I usually draw a little
extra attention to it with either

  (x, ) = iterable

or

  x, = iterable # unpack one value

I'm not sure it qualifies as Pythonic, but it uses Pythonic features
like tuple unpacking and the code is a lot more concise.

-tim





-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pythonic style

[Chris Angelico]

On Mon, Sep 21, 2020 at 11:37 PM Tim Chase
 wrote:
>
> On 2020-09-20 18:34, Stavros Macrakis wrote:
> > Consider a simple function which returns the first element of an
> > iterable if it has exactly one element, and throws an exception
> > otherwise. It should work even if the iterable doesn't terminate.
> > I've written this function in multiple ways, all of which feel a
> > bit clumsy.
> >
> > I'd be interested to hear thoughts on which of these solutions is
> > most Pythonic in style. And of course if there is a more elegant
> > way to solve this, I'm all ears! I'm probably missing something
> > obvious!
>
> You can use tuple unpacking assignment and Python will take care of
> the rest for you:
>
>   >>> x, = tuple() # no elements
>   Traceback (most recent call last):
> File "", line 1, in 
>   ValueError: not enough values to unpack (expected 1, got 0)
>   >>> x, = (1, )  # one element
>   >>> x, = itertools.repeat("hello") # 2 to infinite elements
>   Traceback (most recent call last):
> File "", line 1, in 
>   ValueError: too many values to unpack (expected 1)
>
> so you can do
>
>   def fn(iterable):
> x, = iterable
> return x
>
> The trailing comma can be hard to spot, so I usually draw a little
> extra attention to it with either
>
>   (x, ) = iterable
>
> or
>
>   x, = iterable # unpack one value
>
> I'm not sure it qualifies as Pythonic, but it uses Pythonic features
> like tuple unpacking and the code is a lot more concise.

Or:

[x] = iterable

I'd definitely recommend using unpacking as the most obvious way to do
this. Among other advantages, it gives different messages for the "too
many" and "too few" cases.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pythonic style

[Léo El Amri via Python-list]

On 21/09/2020 15:15, Tim Chase wrote:
> You can use tuple unpacking assignment and Python will take care of
> the rest for you:
> 
> so you can do
> 
>   def fn(iterable):
> x, = iterable
> return x
> 
> I'm not sure it qualifies as Pythonic, but it uses Pythonic features
> like tuple unpacking and the code is a lot more concise.

I guess you just beat the topic. I think it is Pythonic and I'd be
surprised if someone came with something more Pythonic.

FI: The behavior of this assignation is detailed here:
https://docs.python.org/3/reference/simple_stmts.html#assignment-statements
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pythonic style

[Tim Chase]

On 2020-09-21 09:48, Stavros Macrakis wrote:
>>   def fn(iterable):
>> x, = iterable
>> return x
>
> Thanks, Tim! I didn't realize that you could write (x,) on the LHS!
> Very nice, very Pythonic!

It also expands nicely for other cases, so you want the 3-and-only-3
first values with errors for too many or too few?

  x, y, z = iterable
  x, y, z = (1, 2, 3)

The (x,) version is just the single case.  And it's fast—a single
Python UNPACK_SEQUENCE opcode

  >>> dis.dis(fn)
  2   0 LOAD_FAST0 (i)
  2 UNPACK_SEQUENCE  1
  4 STORE_FAST   1 (x)

  3   6 LOAD_FAST1 (x)
  8 RETURN_VALUE

Though now I'm wondering if there's a way to skip the
STORE_FAST/LOAD_FAST instructions and create a function that
generates the opcode sequence

  UNPACK_SEQUENCE 1
  RETURN_VALUE

:-)

(totally tangential ramblings)

-tkc







-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pythonic style

[Frank Millman]

On 2020-09-21 3:46 PM, Chris Angelico wrote:

On Mon, Sep 21, 2020 at 11:37 PM Tim Chase
 wrote:


On 2020-09-20 18:34, Stavros Macrakis wrote:

Consider a simple function which returns the first element of an
iterable if it has exactly one element, and throws an exception
otherwise. It should work even if the iterable doesn't terminate.
I've written this function in multiple ways, all of which feel a
bit clumsy.

I'd be interested to hear thoughts on which of these solutions is
most Pythonic in style. And of course if there is a more elegant
way to solve this, I'm all ears! I'm probably missing something
obvious!


You can use tuple unpacking assignment and Python will take care of
the rest for you:

   >>> x, = tuple() # no elements
   Traceback (most recent call last):
 File "", line 1, in 
   ValueError: not enough values to unpack (expected 1, got 0)
   >>> x, = (1, )  # one element
   >>> x, = itertools.repeat("hello") # 2 to infinite elements
   Traceback (most recent call last):
 File "", line 1, in 
   ValueError: too many values to unpack (expected 1)

so you can do

   def fn(iterable):
 x, = iterable
 return x

The trailing comma can be hard to spot, so I usually draw a little
extra attention to it with either

   (x, ) = iterable

or

   x, = iterable # unpack one value

I'm not sure it qualifies as Pythonic, but it uses Pythonic features
like tuple unpacking and the code is a lot more concise.


Or:

[x] = iterable

I'd definitely recommend using unpacking as the most obvious way to do
this. Among other advantages, it gives different messages for the "too
many" and "too few" cases.



I used something similar years ago, but I made the mistake of relying on 
the error message in my logic, to distinguish between 'too few' and 'too 
many'. Guess what happened - Python changed the wording of the messages, 
and my logic failed.


After messing about with some alternatives, I ended up with the OP's 
first option (with some added comments), and have stuck with it ever 
since. It is not pretty, but it is readable and unambiguous.


Frank Millman

--
https://mail.python.org/mailman/listinfo/python-list

Re: Pythonic style

[Terry Reedy]

On 9/20/2020 6:34 PM, Stavros Macrakis wrote:

I'm trying to improve my Python style.

Consider a simple function which returns the first element of an iterable
if it has exactly one element, and throws an exception otherwise. It should
work even if the iterable doesn't terminate. I've written this function in
multiple ways, all of which feel a bit clumsy.


The 'obvious' thing to me was the double try-except StopIteration.  It 
is clear, and clarity is 'pythonic'.



--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Making Python the Best App Dev Platform

[Bonface M. K.]

Hi!

gMail  writes:

> Hello, All
>
> We all know Python is a wonderful environment,
> with fantastic packages for App Dev like Flask,
> SQLAlchemy and Django.  Now let’s make it the only
> reasonable choice for building database-oriented
> systems.
>
> I’d like to introduce 2 new capabilities:
>
> Build a web app in 10 minutes: this generator
> 
> builds basic multi-page, multi-table apps based on
> Flask AppBuilder and SQLAlchemy; here’s an article
> 
>
> 40x reduction in backend code: this rules engine
>  uses
> spreadsheet-like rules to automate SQLAlchemy
> multi-table derivation and constraint logic.  The
> readme and samples show how 5 rules equate to 200
> lines of code.
>
> The potential value is substantial: a 40X is
> reduction is not only helpful for our projects,
> but has the potential to expand our community.
>
> The second project is in-progress.  If you have
> feedback on the general value or particular
> features, I’d love to hear from you.  And if you’d
> like to help, super!
>
> Best,
> Val

Also, just a suggestion: how about a way to
bootstrap tests. I haven't really seen that on
theGH link shared above.

-- 
Bonface M. K. (https://www.bonfacemunyoki.com)
Chief Emacs Mchochezi / Twitter: @BonfaceKilz
GPG key = D4F09EB110177E03C28E2FE1F5BBAE1E0392253F


signature.asc
Description: PGP signature


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pythonic style

[Stavros Macrakis]

Thanks, Tim! I didn't realize that you could write (x,) on the LHS!
Very nice, very Pythonic!

  -s

On Mon, Sep 21, 2020 at 9:15 AM Tim Chase 
wrote:

> On 2020-09-20 18:34, Stavros Macrakis wrote:
> > Consider a simple function which returns the first element of an
> > iterable if it has exactly one element, and throws an exception
> > otherwise. It should work even if the iterable doesn't terminate.
> > I've written this function in multiple ways, all of which feel a
> > bit clumsy.
> >
> > I'd be interested to hear thoughts on which of these solutions is
> > most Pythonic in style. And of course if there is a more elegant
> > way to solve this, I'm all ears! I'm probably missing something
> > obvious!
>
> You can use tuple unpacking assignment and Python will take care of
> the rest for you:
>
>   >>> x, = tuple() # no elements
>   Traceback (most recent call last):
> File "", line 1, in 
>   ValueError: not enough values to unpack (expected 1, got 0)
>   >>> x, = (1, )  # one element
>   >>> x, = itertools.repeat("hello") # 2 to infinite elements
>   Traceback (most recent call last):
> File "", line 1, in 
>   ValueError: too many values to unpack (expected 1)
>
> so you can do
>
>   def fn(iterable):
> x, = iterable
> return x
>
> The trailing comma can be hard to spot, so I usually draw a little
> extra attention to it with either
>
>   (x, ) = iterable
>
> or
>
>   x, = iterable # unpack one value
>
> I'm not sure it qualifies as Pythonic, but it uses Pythonic features
> like tuple unpacking and the code is a lot more concise.
>
> -tim
>
>
>
>
>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Making Python the Best App Dev Platform

[Bonface M. K.]

[[Cc'ing the python list for other people to give
useful feedback if they can]]

gMail  writes:

> Hi!
>
> Loved your no-place-like-home joke.
>

Thanks!

> Wanted to better understand your question / comment about testing.  
>

From my understanding of what the project does(I
haven't really had a deep dive in it- I've merely
skimmed it), it does a lot of bootstrapping for
you. It would be nice to have unittests(defaulting
to python's unittests would be great). And a way
of running said tests.

> In general, rules don’t affect testing, you just run tests as usual and check 
> the results.  This usually
> consists of reading the “before” data, running the test (an update 
> transaction), and then comparing “after”
> with “before”.  In the past, I wrote a JsonDiff that helped with the 
> comparison.
>

This sounds like manual testing(?). I've grown to
being keen on testing(though I try not to be a
zealot about it). You'd be surprised(IMO) at how
many people don't know how to write tests, usually
not because they don't want to; but because they
don't know /how to/.

> What did you have in mind?
>

That being said, it would be nice to see your
project have that-- doing bootstrapping for tests
for you; and having somewhere that mentions how to
run them. I'll try to have a look at it over the
weekend? That's seems like something I'd use-
though it'd have to be more generic.

> Best,
> Val
>
> On Sep 21, 2020, at 10:00 AM, Bonface M. K.  
> wrote:
>
> Hi!
>
> gMail  writes:
>
> Hello, All
>
> We all know Python is a wonderful environment,
> with fantastic packages for App Dev like Flask,
> SQLAlchemy and Django.  Now let’s make it the only
> reasonable choice for building database-oriented
> systems.
>
> I’d like to introduce 2 new capabilities:
>
> Build a web app in 10 minutes: this generator
> 
> builds basic multi-page, multi-table apps based on
> Flask AppBuilder and SQLAlchemy; here’s an article
> 
>
> 40x reduction in backend code: this rules engine
>  uses
> spreadsheet-like rules to automate SQLAlchemy
> multi-table derivation and constraint logic.  The
> readme and samples show how 5 rules equate to 200
> lines of code.
>
> The potential value is substantial: a 40X is
> reduction is not only helpful for our projects,
> but has the potential to expand our community.
>
> The second project is in-progress.  If you have
> feedback on the general value or particular
> features, I’d love to hear from you.  And if you’d
> like to help, super!
>
> Best,
> Val
>
> Also, just a suggestion: how about a way to
> bootstrap tests. I haven't really seen that on
> theGH link shared above.
>
> -- 
> Bonface M. K. (https://www.bonfacemunyoki.com)
> Chief Emacs Mchochezi / Twitter: @BonfaceKilz
> GPG key = D4F09EB110177E03C28E2FE1F5BBAE1E0392253F

-- 
Bonface M. K. (https://www.bonfacemunyoki.com)
Chief Emacs Mchochezi / Twitter: @BonfaceKilz
GPG key = D4F09EB110177E03C28E2FE1F5BBAE1E0392253F


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list