Re: Sketch

[Mr Flibble]

On 14/02/2021 09:10, Michał Jaworski wrote:

Wow, that thread is entertaining. It seems that neos is one of it’s kind. What 
I hope is that it will support TempleOS.

Going back going back to your original question Mr. Fibble. If ISO standard is 
what you really need to finish your project you can always take up this 
challenge and standardize the language yourself. From what I’ve learned already 
you have enough skills, experience and perseverance to complete such endeavor 
single-handedly.


Ah yes, the good old TempleOS equivalence ploy: typically used by backseat 
programmers and/or trolls to dismiss projects or project authors they deem to 
have no value based on subjective hyperbole rather than valid criticism based 
on objective fact. Usually they lack the skill to embark on such a project 
themselves so their invective tends to stem from feelings of inadequacy.

Make yourself a cup of tea, dear.

/Flibble

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

Re: Sketch

[Mr Flibble]

On 14/02/2021 09:10, Michał Jaworski wrote:

Wow, that thread is entertaining. It seems that neos is one of it’s kind. What 
I hope is that it will support TempleOS.

Going back going back to your original question Mr. Fibble. If ISO standard is 
what you really need to finish your project you can always take up this 
challenge and standardize the language yourself. From what I’ve learned already 
you have enough skills, experience and perseverance to complete such endeavor 
single-handedly.


If I standardized the language myself I couldn't call it "Python" as fixing 
Python requires changing it such as to make it unrecognisable as Python.

/Flibble

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

Fwd: Sketch

[Igor Korot]

-- Forwarded message -
From: Igor Korot 
Date: Sat, Feb 13, 2021, 9:20 PM
Subject: Re: Sketch
To: Mr Flibble 
Cc: 


Hi,



On Sat, Feb 13, 2021, 9:12 PM Mr Flibble 
wrote:

> On 14/02/2021 05:04, Mark Lawrence wrote:
> > On Sunday, February 14, 2021 at 5:01:46 AM UTC, Mr Flibble wrote:
> >> CPython *is* the dead parrot.
> >>
> >> It's time for Python to evolve out of the primordial soup.
> >>
> >> /Flibble
>

Is there a proof?
Because I could say that JAVA sucks, but without proof it will be just
words...

Thank you.

>>
> >> --
> >> 
> >
> > Says the bloke(?) who doesn't use mailing lists but does get here
> https://mail.python.org/pipermail/python-list/2021-February/900797.html
>
> I am using Usenet, dear. Apparently posts to comp.lang.python are copied
> to the mailing list which you worship like a god.
>
> /Flibble
>
> --
> 
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Sketch

[Michał Jaworski]

Wow, that thread is entertaining. It seems that neos is one of it’s kind. What 
I hope is that it will support TempleOS.

Going back going back to your original question Mr. Fibble. If ISO standard is 
what you really need to finish your project you can always take up this 
challenge and standardize the language yourself. From what I’ve learned already 
you have enough skills, experience and perseverance to complete such endeavor 
single-handedly.

Michał Jaworski
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Sketch

[Igor Korot]

Hi,



On Sat, Feb 13, 2021, 9:12 PM Mr Flibble 
wrote:

> On 14/02/2021 05:04, Mark Lawrence wrote:
> > On Sunday, February 14, 2021 at 5:01:46 AM UTC, Mr Flibble wrote:
> >> CPython *is* the dead parrot.
> >>
> >> It's time for Python to evolve out of the primordial soup.
> >>
> >> /Flibble
>

Is there a proof?
Because I could say that JAVA sucks, but without proof it will be just
words...

Thank you.

>>
> >> --
> >> 
> >
> > Says the bloke(?) who doesn't use mailing lists but does get here
> https://mail.python.org/pipermail/python-list/2021-February/900797.html
>
> I am using Usenet, dear. Apparently posts to comp.lang.python are copied
> to the mailing list which you worship like a god.
>
> /Flibble
>
> --
> 
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Sketch

[Mr Flibble]

On 14/02/2021 05:04, Mark Lawrence wrote:

On Sunday, February 14, 2021 at 5:01:46 AM UTC, Mr Flibble wrote:

CPython *is* the dead parrot.

It's time for Python to evolve out of the primordial soup.

/Flibble

--



Says the bloke(?) who doesn't use mailing lists but does get here 
https://mail.python.org/pipermail/python-list/2021-February/900797.html


I am using Usenet, dear. Apparently posts to comp.lang.python are copied to the 
mailing list which you worship like a god.

/Flibble

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

Sketch

[Mr Flibble]

CPython *is* the dead parrot.

It's time for Python to evolve out of the primordial soup.

/Flibble

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

[issue40387] queue example is a sketch

[Raymond Hettinger]

Change by Raymond Hettinger :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40387] queue example is a sketch

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset 179f22c3b786ce9baa3445923f8f9708dfa5d5b7 by Miss Islington (bot) 
in branch '3.8':
bpo-40387: Improve queue join() example. (GH-19724) (GH-19726)
https://github.com/python/cpython/commit/179f22c3b786ce9baa3445923f8f9708dfa5d5b7


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40387] queue example is a sketch

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +19048
pull_request: https://github.com/python/cpython/pull/19726

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40387] queue example is a sketch

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset 88499f15f547ccf7b15d37b0eaf51cc40bad5c39 by Raymond Hettinger in 
branch 'master':
bpo-40387: Improve queue join() example. (GH-19724)
https://github.com/python/cpython/commit/88499f15f547ccf7b15d37b0eaf51cc40bad5c39


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40387] queue example is a sketch

[Santiago Blanco]

Santiago Blanco  added the comment:

That is pretty clear! Thank you Raymond.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40387] queue example is a sketch

[Raymond Hettinger]

Change by Raymond Hettinger :


--
pull_requests: +19046
pull_request: https://github.com/python/cpython/pull/19724

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40387] queue example is a sketch

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I'm thinking of simplifying the example to focus on its core goal of 
demonstrating how to enqueue tasks and then wait for them to be finished:

import threading, queue

q = queue.Queue()

def worker():
while True:
item = q.get()
print(f'Working on {item}')
print(f'Finished {item}')
q.task_done()

# turn-on the worker thread
worker_thread = threading.Thread(target=worker)
worker_thread.daemon = True
worker_thread.start()

# send thirty task requests to the worker
for item in range(30):
q.put(item)
print('All task requests sent\n', end='')

# block until all tasks are done
q.join()
print('All work completed')

--
assignee: docs@python -> rhettinger
title: queue example it does not work -> queue example is a sketch
versions:  -Python 3.7

___
Python tracker 
<https://bugs.python.org/issue40387>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

1st Sketch at at ReadOnly dict

[Charles Hixson]

This is just a first sketch, and I haven't yet attempted to test it, so 
what I'm hoping for is criticisms on the general approach.


##Read Only dict class.
#@note Instances can be created only from existing dicts.
#@warningvalues within the RODict can be accessed, so if they hold
#references to other items, they can be altered.
class RODict:
#Instance Variable Doc
##@var_ddict
#This variable holds the reference to the dict.

##Class initializer.
#@paramddictThe data dictionary to which this is a read 
only

#access.
#@throwsTypeError if ddict is not a dict.
def __init__ (self, ddict = {}):
if not isinstance(ddict, dict):
raiseTypeError(ddict must be a dict.  It is  + 
repr(ddict))

self._ddict=ddict

##Test for containment.
#@paramkeyThe item to be found.
#@returnTrueIf key is in the instance, otherwise False.
def __contains__(self, key):
returnkey in self._ddict

##Pass along the __getitem call.
def __getitem__(self, key):
returnself._ddict.__getitem__(key)

##Pass along the get call.
def get (self, key, default = None):
returnself._ddict.get(key, default)

##Return a DictView of the items of the instance.
def items(self):
returnself._ddict.items()

##Return a DictView of the keys of the instance.
def keys(self):
returnself._ddict.keys()

##Return a DictView of the values of the instance.
def values(self):
returnself._ddict.values()


##Return the length of the dict.
def __len__(self):
returnlen(self._ddict)

--
Charles Hixson

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

Re: 1st Sketch at at ReadOnly dict

[Peter Otten]

Charles Hixson wrote:

 This is just a first sketch, and I haven't yet attempted to test it, so
 what I'm hoping for is criticisms on the general approach.
 
 class RODict:

  def __init__ (self, ddict = {}):

Default values are evaluted just once when the method is created. Mutable 
default values mean trouble:

 class D:
... def __init__(self, dict={}):
... self.dict = dict
... def __setitem__(self, key, value):
... self.dict[key] = value
... def __repr__(self): return repr(self.dict)
... 
 d1 = D()
 d2 = D()
 d1[1] = 42
 d2[2] = 42
 d1
{1: 42, 2: 42}
 d2
{1: 42, 2: 42}

  if not isinstance(ddict, dict):
  raiseTypeError(ddict must be a dict.  It is  +
 repr(ddict))
  self._ddict=ddict

I think instead of the type check I would build a new dict from the 
argument. The usual initializers

dict({1:2, 3:4})
dict([(1,2), (3,4)])
dict(a=1, b=2)

should work with your read-only dict.

 
  ##Test for containment.
  #@paramkeyThe item to be found.
  #@returnTrueIf key is in the instance, otherwise False.

Docstrings are usually prefered over comments like the above.

  def __contains__(self, key):
  returnkey in self._ddict

Did you know

http://docs.python.org/dev/library/collections.abc.html#collections.abc.Mapping

Subclass from it to ensure that all the usuall methods are defined.

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

Re: 1st Sketch at at ReadOnly dict

[Peter Otten]

Peter Otten wrote:

 Charles Hixson wrote:
 
 This is just a first sketch, and I haven't yet attempted to test it, so
 what I'm hoping for is criticisms on the general approach.
 
 class RODict:
 
  def __init__ (self, ddict = {}):
 
 Default values are evaluted just once when the method is created. Mutable
 default values mean trouble:
 
 class D:
 ... def __init__(self, dict={}):
 ... self.dict = dict
 ... def __setitem__(self, key, value):
 ... self.dict[key] = value
 ... def __repr__(self): return repr(self.dict)
 ...
 d1 = D()
 d2 = D()
 d1[1] = 42
 d2[2] = 42
 d1
 {1: 42, 2: 42}
 d2
 {1: 42, 2: 42}

D'oh, that was just and instintive reaction.

You may already know that... Of course it doesn't matter as long as no 
attempt is made to mutate the mutable value.

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

Re: 1st Sketch at at ReadOnly dict

[Charles Hixson]

On 01/20/2014 12:52 PM, Peter Otten wrote:

Charles Hixson wrote:


This is just a first sketch, and I haven't yet attempted to test it, so
what I'm hoping for is criticisms on the general approach.

class RODict:
  def __init__ (self, ddict = {}):

Default values are evaluted just once when the method is created. Mutable
default values mean trouble:


class D:

... def __init__(self, dict={}):
... self.dict = dict
... def __setitem__(self, key, value):
... self.dict[key] = value
... def __repr__(self): return repr(self.dict)
...

d1 = D()
d2 = D()
d1[1] = 42
d2[2] = 42
d1

{1: 42, 2: 42}

d2

{1: 42, 2: 42}


  if not isinstance(ddict, dict):
  raiseTypeError(ddict must be a dict.  It is  +
repr(ddict))
  self._ddict=ddict

I think instead of the type check I would build a new dict from the
argument. The usual initializers

dict({1:2, 3:4})
dict([(1,2), (3,4)])
dict(a=1, b=2)

should work with your read-only dict.


  ##Test for containment.
  #@paramkeyThe item to be found.
  #@returnTrueIf key is in the instance, otherwise False.

Docstrings are usually prefered over comments like the above.


  def __contains__(self, key):
  returnkey in self._ddict

Did you know

http://docs.python.org/dev/library/collections.abc.html#collections.abc.Mapping

Subclass from it to ensure that all the usuall methods are defined.

That link, 
http://docs.python.org/dev/library/collections.abc.html#collections.abc.Mapping 
, is a very good one.  I hadn't realized that it separated Mapping from 
MutableMapping.
It would be nice if there were some examples of it's usage around, 
though.  I can't really tell how to use it.  (E.g., it mixes in 
__contains__, but it doesn't show how to specify what you are testing 
for cotainment in.  So it looks as if I need to specify everything 
anyway because I can't tell what might be implemented in some 
inappropriate way.)  OTOH, it's a good list of what needs to be 
implemented.  (I see that I left out implementation of eq and ne, which 
is pretty straightfoward, but apparently needed (unless it's 
automatically being handled by the mixin...which I can't tell).


--
Charles Hixson

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

Re: 1st Sketch at at ReadOnly dict

[Chris Angelico]

On Tue, Jan 21, 2014 at 7:09 AM, Charles Hixson
charleshi...@earthlink.net wrote:
 #@note Instances can be created only from existing dicts.

 ##Class initializer.
 #@paramddictThe data dictionary to which this is a read only
 #access.
 #@throwsTypeError if ddict is not a dict.
 def __init__ (self, ddict = {}):
 if not isinstance(ddict, dict):
 raiseTypeError(ddict must be a dict.  It is  +
 repr(ddict))
 self._ddict=ddict

Instead of demanding that a dict (or dict subclass) be passed, why not
simply pass all args on to dict() itself? Is there a reason this won't
work?

def __init__(self, *args, **kwargs):
self._ddict = dict(*args, **kwargs)

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

Re: 1st Sketch at at ReadOnly dict

[Charles Hixson]

On 01/20/2014 04:08 PM, Chris Angelico wrote:

On Tue, Jan 21, 2014 at 7:09 AM, Charles Hixson
charleshi...@earthlink.net wrote:

#@note Instances can be created only from existing dicts.

 ##Class initializer.
 #@paramddictThe data dictionary to which this is a read only
 #access.
 #@throwsTypeError if ddict is not a dict.
 def __init__ (self, ddict = {}):
 if not isinstance(ddict, dict):
 raiseTypeError(ddict must be a dict.  It is  +
repr(ddict))
 self._ddict=ddict

Instead of demanding that a dict (or dict subclass) be passed, why not
simply pass all args on to dict() itself? Is there a reason this won't
work?

def __init__(self, *args, **kwargs):
 self._ddict = dict(*args, **kwargs)

ChrisA
It would work, as long as it would work for dict(), but I have been 
expecting to use it in situations where it would be useful to have a 
different access to the dict that would be writeable.  So I didn't 
bother.  (Well, and took steps to ensure that it was being used in the 
manner that I expected.  So I'd know to change it if it were 
appropriate.)  It *would* make it more difficult for the class to test 
it's creation arguments for sanity, though.  (One could argue that 
allowing read only access to an empty dict is violating sanity, but I 
don't think in any dangerous way.)  I do sometimes worry that using 
isinstance excessively is overly expensive.  Perhaps I should wrap them 
with a test for debug mode.



--
Charles Hixson

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

Re: 1st Sketch at at ReadOnly dict

[Dan Stromberg]

On Mon, Jan 20, 2014 at 12:09 PM, Charles Hixson
charleshi...@earthlink.net wrote:

 class RODict:
 #Instance Variable Doc
 ##@var_ddict
 #This variable holds the reference to the dict.

 ##Class initializer.
 #@paramddictThe data dictionary to which this is a read only
 #access.
 #@throwsTypeError if ddict is not a dict.
 def __init__ (self, ddict = {}):
 if not isinstance(ddict, dict):
 raiseTypeError(ddict must be a dict.  It is  +
 repr(ddict))
 self._ddict=ddict

When I see this isinstance, I think Gee, that means none of the
dict-like-objects I recently compared would work with this class.

The comparison is at the URL below; all the things compared are trees
that provide a dictionary-like interface, but also find_min, find_max
and can iterate in key order.  I don't think any of them inherit from
dict, but they are all dict-like in a duck-typed sense:

http://stromberg.dnsalias.org/~strombrg/python-tree-and-heap-comparison/2014-01/

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

Re: 1st Sketch at at ReadOnly dict

[Charles Hixson]

On 01/20/2014 08:14 PM, Dan Stromberg wrote:

On Mon, Jan 20, 2014 at 12:09 PM, Charles Hixson
charleshi...@earthlink.net wrote:


class RODict:
 #Instance Variable Doc
 ##@var_ddict
 #This variable holds the reference to the dict.

 ##Class initializer.
 #@paramddictThe data dictionary to which this is a read only
 #access.
 #@throwsTypeError if ddict is not a dict.
 def __init__ (self, ddict = {}):
 if not isinstance(ddict, dict):
 raiseTypeError(ddict must be a dict.  It is  +
repr(ddict))
 self._ddict=ddict

When I see this isinstance, I think Gee, that means none of the
dict-like-objects I recently compared would work with this class.

The comparison is at the URL below; all the things compared are trees
that provide a dictionary-like interface, but also find_min, find_max
and can iterate in key order.  I don't think any of them inherit from
dict, but they are all dict-like in a duck-typed sense:

http://stromberg.dnsalias.org/~strombrg/python-tree-and-heap-comparison/2014-01/

HTH

Well, it would mean you couldn't create instances of this class from 
them.  I haven't yet specified the eq and ne methods, but they'd 
probably be something like:

def ne(self, key):
return self._ddict.ne(key)
(I'd need to look up the precise names of the comparison routines. 
Perhaps it would be __ne__ rather than ne.)
So if they'd work with a normal dict, they should work with this, for 
comparison.


Note that this is a dict-alike, and therefore not in a predictable 
order.  If the items were to be ordered, however, they would be in order 
by the value rather than by the key, as my use-case is most likely to 
want to access the items with the highest value most often.   I may even 
decide to use a list of lists, but a dict yields simpler code, even if I 
suspect that lists might be more efficient. But the choice of list would 
mean I could use a tuple, which because it is standard would also tend 
to make things simpler.  (It wouldn't, however, allow background 
updating, as dictviews do, and also RODict does, so I'd need to find 
some way to manage that...probably meaning that I'd need to regenerate 
them more often.)


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

Rough sketch of a PEP for issue2292

[Joshua Landau]

In order to get the ball rolling, and because after hours of futzing I
still can't get the diff to work (yeah, fine, I'm incompetent), I've
started sketching out how a PEP for http://bugs.python.org/issue2292,
Missing *-unpacking generalizations might look.

It's attached if anyone cares to look. You can insult me over it if
you want, but I'd prefer if you liked it :P. I also don't mind
additions to it if you feel you want to waste some time.

If anyone knows how to get the patch (from the bug report) working, or
where to find
http://code.python.org/python/users/twouters/starunpack after
code.python.org was deleted in favour of hg.python.org (which seems
not to have it), that'd be nice too.

Again, this is a sketch. It's incomplete and I'm likely to replace
large parts of it tomorrow. There's also very little justification and, I
think, there are too many code blocks. So it's all liable to change.
PEP: XXX
Title: Additional Unpacking Generalizations
Version: $Revision$
Last-Modified: $Date$
Author: Joshua Landau jos...@landau.ws
Discussions-To: python-id...@python.org
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 29-Jun-2013
Python-Version: 3.4
Post-History: #TODO


Abstract


This PEP proposes extended usages of the ``*`` iterable unpacking operator.

Specifically:

Multiple unpackings::

 print(*[1], *[2])
1 2
 dict(**{'x': 1}, **{'y': 2})
{'x': 1, 'y': 2}

Unpacking does not prevent further arguments being passed::

 print(*[1], 2)
1 2
 dict(**{'x': 1}, y=2)
{'x': 1, 'y': 2}
 def f(*args, last): pass

Keywords arguments must still follow positional arguments but now must also 
follow ``*``-unpackings. The function of a lone ``*`` in function definitions 
is unchanged.

Unpacking inside tuples, lists, sets and dictionaries, and comprehensions for 
iterators, lists, sets and dictionaries::

 *range(4), 4
(0, 1, 2, 3, 4)
 [*range(4), 4]
[0, 1, 2, 3, 4]
 {*range(4), 4}
{0, 1, 2, 3, 4}
 {'x': 1, **{'y': 2}}
{'x': 1, 'y': 2}

 ranges = [range(i) for i in range(5)]

 [*item for item in ranges]
[0, 0, 1, 0, 1, 2, 0, 1, 2, 3]


Rationale
=

Current usage of the ``*`` iterable unpacking operator features somewhat 
arbitrary restrictions.

A limitation of one unpacking per function call makes some function calls more 
verbose than necessary; instead of::

function(**arguments, **more_arguments)

one is forced to write::

kwargs = arguments.copy()
kwargs.update(more_arguments)
function(**kwargs)

or, if they know to do so::

from collections import ChainMap
function(**ChainMap(more_arguments, arguments))

This also applies to any circumstance where you would like to unpack positional 
arguments followed by another positional argument::

function(*args, arg)


Function definitions are also now more symmetrical with assignment; whereas 
previously just::

first, *others, last = iterable

was valid, now so too is::

def f(first, *others, last):
...

f(*iterable)


There are two primary rationale for unpacking inside of containers. Firstly, it 
would make sense for::

lst = (1, 2, 3, 4, 5)
first, *others, last = lst

to be the inverse of::

first, others, last = 1, [2, 3, 4], 5
lst = first, *others, last


Secondly, it vastly simplifies dictionary addition such as::

combination = first_dictionary.copy()
combination.update({x: 1, y: 2})

and equivalents, as now you can just write::

combination = {**first_dictionary, x: 1, y: 2}

which is especially important in contexts where expressions are preferred. This 
can also help replace ``lst + [item]``.


Specification
=

This isn't my forté, so it will take a bit longer.

Function calls may accept an unbound number of ``*`` and ``**`` unpackings, 
which are allowed anywhere that positional and keyword arguments are allowed 
respectively. In approximate pseudo-notation:

::

function_call(
[(*args|arg), ]...
[(**kwargs|kwarg=expr), ]...
)

The function ``lambda *args, last: ...`` now does not require ``last`` to be a 
keyword only argument, and thus::

def func(*args, *, keyword_only):
...

is valid. Otherwise, function definitions remain unchanged.


Tuples, lists, sets and dictionaries now allow unpacking. Dictionaries require 
``**`` unpacking, all the others require ``*`` unpacking. A dictionary's key 
remain in a right-to-left priority order, so ``{**{'a': 1}, 'a': 2, **{'a': 
3}}`` evaluates to ``{'a': 3}``.


**I am unclear on what the definition for comprehensions should be: should** 
``{**d for d in dicts}`` **work as well as** ``{*s for s in sets}`` **par 
exemple?**


Backwards-Incompatibility
=

Parts of this change are not backwards-compatible.

- ``function(kwarg=foo, *args)`` is no longer valid syntax; ``function(*args, 
kwarg=foo)`` is required instead

- ``lambda *args, last: ...`` no longer

Python and Wacom Tablets (digitizing tablets) for sketch input

[Gabe Johnson]

Hello Python people,

Does anybody have experience using Python and digitizing tablets such
as a Wacom Tablet? I would like to know if Python is capable of giving
you the high-resolution data from the tablet, or if it truncates it to
low-res integers like Java.

I have been developing some sketch recognition systems in Java, using a
Wacom Tablet (one of the cheap ones). I do not know if the problem is
at the OS level or the JVM level, but the data that I am getting from
the tablet (via Java's mouse event dispatch system) is low-resolution.
I receive tablet input in terms of integer coordinates, but the tablet
is actually giving the OS high resolution data. I do know that somebody
has hacked a JNI library to access the raw tablet data, but that is for
Windows only, and I need my application to run on any machine.

I'm also desperately trying to flee to a better language for quickly
throwing together prototypes. Java imposes too much structure, so I was
hoping to use something like Ruby or Python.

Thanks.

Gabe gabe.johnson@ google's web mail service

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