issue

2009-01-19 Thread amin
Hi dears.
I started programing with python and want to use a suitable
database.But I Know nothing about them.please introduse one to me.
thanks.
--
http://mail.python.org/mailman/listinfo/python-list


lambdak: multi-line lambda implementation in native Python

2015-01-14 Thread yawar . amin
Hi all,

First off, to each reader--if you believe that 'multi-line' lambdas are
no good and we can just use functions, decorators, &c. to accomplish
everything in Python, advance warning: this post will annoy you.

Now, the crux of my message. I have implemented what I believe is a
fairly robust, if ugly-looking, native Python module made up of
combinator functions which compose together to form function expressions
(well, callable expressions).

I've seen a lot of discussions on possibly introducing syntax support
for multi-line lambdas in some future version, but I've never seen
anyone say, here's a way you can do this in Python _today._ So I believe
lambdak fits in that niche.

https://github.com/yawaramin/lambdak

Would anyone care to try it out? I would be happy to answer questions
whenever I can.

Regards,

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


Re: lambdak: multi-line lambda implementation in native Python

2015-01-15 Thread Yawar Amin
On Thursday, January 15, 2015 at 1:40:09 AM UTC-5, Ian wrote:
> On Wed, Jan 14, 2015 at 11:06 PM, Steven D'Aprano
>  wrote:
> [...]
> > def func(a, b=None):
> > global spam
> > import math
> > spam = [a, b]*3
> > print spam
> > del spam
> >
> > value = [1, "hello", int, func]
> > del func
> [...]
> # Untested, but seems like this should work.
> [...]
> To the OP: I note that although import_ is used in the examples, it's
> not found in the list of functions in the README.

Thanks Ian. I'll update the readme soon. It's still a little behind the
actual code.

Steve, here is your example translated, about as simple as I can make
it:

from lambdak import *

value = [
  1,
  "hello",
  int,
  given_(lambda a, b = None:
import_("math", lambda math:
given_(lambda globs = globals(), spam = "spam":

assign_(spam, [a, b] * 3, globs, lambda:
print_(get_(spam, globs), lambda:
del_(spam, globs))
]

value[3](1)
del value[3]

The problem with globals is that a Python module can't easily manipulate
the globals of its caller modules. Here you can see I had to work around
the issue by just creating a few functions[1] which generically work
with dicts and then explicitly passing in the globals dict on each call.
I don't see any other reasonable way to do it. I would welcome being
proven wrong here.

To the responders in the 'beauty of the code' subthread: yes, I realise
that lambdak is not Pythonic, and it will make angels cry, and all that.
My view is you should actually be _happy_ that it looks like this. If
anyone ever asks about multi-line lambdas again, you can point to
lambdak and say, 'See! This is what happens if you try to go against
Pythonic style.' And then you can shrug your head in disgust if they
continue to use it anyway.

Regards,

Yawar

[1] `assign_`, `get_`, `del_`. I haven't pushed these to the project
repo yet. Will do so after writing up the tests and docs.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: lambdak: multi-line lambda implementation in native Python

2015-01-15 Thread Yawar Amin
Hi,

On Thursday, January 15, 2015 at 12:19:31 PM UTC-5, Rustom Mody wrote:
> [...]
> Looked at your suggestions...
> And then got distracted by your other project
> https://github.com/yawaramin/vim-cute-python
> 
> Reminded me of what I had written some months ago along similar lines
> http://blog.languager.org/2014/04/unicoded-python.html
> 
> At that time this was not suggested quite seriously.
> Now I see that this can be realized at least partially
> and on a personal level.

Glad it was useful. Although let me clarify that I just forked the repo
from the original on GitHub, to publish my custom version. I have more
conservative tastes than the original, so I chose to keep the `in`, `not
in`, `and`, `or`, `not` keywords as is instead of using the symbols. I
did go through your blog post and got a previously-unused symbol out of
it: '÷' to represent '/'.

Regards,

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


Re: lambdak: multi-line lambda implementation in native Python

2015-01-15 Thread Yawar Amin
On Thursday, January 15, 2015 at 10:06:34 PM UTC-5, Rick Johnson wrote:
> [...]
> Well i'm not religious in that way, but i can tell you that
> you'd be hard pressed to find a subject that did *NOT*
> annoy someone in this group. Heck, it might even be
> something like finding a "holy grail" if we all agreed!

Ha! Indeed. And here I was thinking that Python's Holy Grail would be
finding a good multi-line lambda :-)

> Oh my, that's atrocious! (but kudos for trying!). If you
> have not already done so, i would suggest you play around
> with the Ruby language -- for which anonymous blocks are
> quite prevalent.

Yes, I've been very impressed by Ruby's æsthetics. Matz did something
with Ruby that few other people were willing to do: he followed
expression semantics to its logical conclusion. People (including
myself) have asked if we could have that in Python, but as I understand
it Python has some strict newline and indent requirements that prevent
it.

> I myself have lamented the limited power and expressiveness
> of Python's anonymous functions. It's almost as though
> Python lambda's are barely worth having since they are so
> crippled.

I guess they are crippled from the perspective of a functional
programmer. But they work pretty well for their intended uses. And as I
mentioned, if your editor masks the keyword and displays the symbol,
they almost look natural in the code.

Regards,

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


Re: recursive function: use a global or pass a parameter?

2015-01-16 Thread Yawar Amin
On Friday, January 16, 2015 at 1:34:51 PM UTC-5, Peter Otten wrote:
> [...]
> I recommend that you use a generator:
> 
> >>> def walk(obj):
> ... if not hasattr(obj, "keys"):
> ... return
> ... if "things" in obj:
> ... yield obj["things"]
> ... for v in obj.values():
> ... yield from walk(v)

Cool ... but it looks like this can still potentially hit the max
recursion limit? Perhaps better to convert to an iterative style:

def walk(obj):
  """
  Yield any value(s) contained within `obj` that is (are) indexed by
  the key 'things'. `obj` must be dict-like.
  """
  from collections import deque
  vals = deque()
  vals.append(obj)

  while True:
try: curr_obj = vals.popleft()
except IndexError: return
if not hasattr(curr_obj, "keys"): continue

if "things" in curr_obj: yield curr_obj["things"]
vals.extend(curr_obj.values())

# Examples

d1 = list(walk({ "things": 1, "two": { "things": 2 } }))

d2 = list(walk({
  "things": 1,
  "two": { "things": 2 },
  "three":
{ "four": 4,
  "things":
{ "five": 5,
  "six": 6,
  "things":
{ "seven": 7,
  "things": 8 } } } }))

So this effectively 'flattens' a dictionary at each level into a queue
made up of the dictionary's values, and meanwhile yields the values one
by one if they are indexed by the key 'things'.

The output for `d1` should be the same as Peter Otten's example, except
I'm using a list instead of a set because I think the yielded objects
could themselves be dictionaries or other non-hashable values.

When you're looking at the output for `d2`, remember that `walk` here
will yield _any_ object that's indexed by the key, and as I mentioned,
that could be an entire dictionary object contained within the main one.

Regards,

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


Re: recursive function: use a global or pass a parameter?

2015-01-16 Thread Yawar Amin
On Friday, January 16, 2015 at 9:24:15 PM UTC-5, Yawar Amin wrote:
> [...]
> vals.extend(curr_obj.values())

Ah, I should mention that the above will do a breadth-first search. If
we want to do a depth-first search we simply replace the above line
with:

vals.extendleft(curr_obj.values())

Regards,

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


Re: Alternative to multi-line lambdas: Assign-anywhere def statements

2015-01-24 Thread Yawar Amin
Hi,

On Saturday, January 24, 2015 at 3:36:04 PM UTC-5, Devin Jeanpierre
wrote:
> [...]
> Obviously, nobody will be happy until you can do:
> 
> def call(*a, **kw): return lambda f: f(*a, **kw)
> 
> @call()
> def x, y ():
> yield 1
> yield 2
> 
> Actually, maybe not even then.

You're probably right, because someone already _has_ come up with that: 


https://github.com/carymrobbins/python-blocks/blob/f51d10bd2439990cce7e2cb78e6e56ed05e78648/src/blocks.py#L191

Anyway Chris, to answer your question, the python-blocks repo shows the
'functional decorator style' taken to its logical conclusion, with
decorators for all the various functional building blocks like mapping,
folding, currying, etc.

Incidentally, with a properly-defined decorator 'factory', you could get
a pretty generic decorator for your dispatch example:

cmd = {}
dispatch = make_dispatch(cmd)

@dispatch
def foo(*args): print("You asked to foo.")

@dispatch
def bar(*args): print("There's no wine in the bar.")

@dispatch
def cmd2(*args): print("Asdf! Asdf!")

cmd["foo"]()
# Etc.

Regards,

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


Re: Alternative to multi-line lambdas: Assign-anywhere def statements

2015-01-24 Thread Yawar Amin
Hi Ethan,

On Saturday, January 24, 2015 at 9:00:12 PM UTC-5, Ethan Furman wrote:
> [...]
> __name__ being one of them.  One of the reasons lambda
> is not encouraged is because its name is always '', which just
> ain't helpful when the smelly becomes air borne!  ;)

Doesn't the traceback tell us exactly where the lambda was called from?

Regards,

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


Re: Alternative to multi-line lambdas: Assign-anywhere def statements

2015-01-25 Thread Yawar Amin
Hi Steven,

On Saturday, January 24, 2015 at 11:27:33 PM UTC-5, Steven D'Aprano
wrote:
> [...]
> > Doesn't the traceback tell us exactly where the lambda was called
> > from?
> 
> Yes (assuming the source code is available, which it may not be), but

If the source code is not available, then you're equally unable to debug
a lambda function and a named function.

> even so, which is easier?
> 
> "Oh, the exception occurred in myfunc"
> 
> versus
> 
> "Hmmm, the exception occurred in a lambda, lets see now, that was
> called by "f", but f might have called seven different lambdas, which
> [...]

True, Python's current traceback reporting doesn't tell us the exact
column number on which the exception occurred. So for example with this:

print((lambda: 1)(), (lambda: 1 / 0)())

You will get the following traceback:

Traceback (most recent call last):
  File "test.py", line 3, in 
print((lambda: 1)(), (lambda: 1 / 0)())
  File "test.py", line 3, in 
print((lambda: 1)(), (lambda: 1 / 0)())
ZeroDivisionError: integer division or modulo by zero

So the problem is there are two lambdas in line 3, so you need to
examine them both to figure out which one caused the exception. The
simple solution to this is to just put the lambdas on different lines:

print(
  (lambda: 1)(),
  (lambda: 1 / 0)()
)

Now you get a blindingly obvious traceback:

Traceback (most recent call last):
  File "test.py", line 5, in 
(lambda: 1 / 0)()
  File "test.py", line 5, in 
(lambda: 1 / 0)()
ZeroDivisionError: integer division or modulo by zero


> Using lambda is trading off convenience when writing the code for ease
> of debugging the code when a problem occurs. Whether that trade-off is
> worthwhile or not depends on factors such as how likely the lambda is
> to have a bug, how many of them there are, and whether or not there is
> uncertainty as to which one is called from where.

I feel like this whole 'debugging' argument is a red herring, because
you can have _many_ different expressions in a line of code all of which
could have potentially caused an exception you're trying to debug. For
example, dispensing with the lambdas:

print(1, 1 / 0)

Error:

Traceback (most recent call last):
  File "test.py", line 3, in 
print(1, 1 / 0)
ZeroDivisionError: integer division or modulo by zero

Again, it all comes down to Python just not telling you precisely where
the error occurred, and instead only giving you the general vicinity.
Again, this can be fixed simply by just putting the expressions on
different lines.

Regards,

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


GUI

2017-01-28 Thread hany . amin . mishriky
hay , i am new in the coding world,i would like to understand how a python 
program is communicating with GUI, for example, if i have a code that require 
the user to enter a value ,then this code will do some calculations and return 
a value to the user, how to do that?
-- 
https://mail.python.org/mailman/listinfo/python-list