must be dicts in tuple

[Tanaya D]

Hi,

I am using Python with Bots(EDI translator)

But i am getting the following error:
MappingFormatError: must be dicts in tuple: get((({'BOTSID': 'HEADER'},),))

Can anyone pls help me with it.

Thanks

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

Re: Python3, GUIs, game APIs, PyGLet, 2to3...?

[John Ladasky]

Followup to my own post: I've made progress with PyGLet.  I should mention that 
I'm using Ubuntu Linux 13.04 64-bit, in case it matters.

I tried executing "2to3 -w *.py" on just the files in the directory 
pyglet-1.2alpha1/pyglet.  I then changed back to the pyglet-1.2alpha1 
directory, and executed "sudo python setup.py install".  Finally, I started my 
Python3 interpreter.  This time, "import pyglet" generated no errors.

The PyGLet "Hello, World" code found on this web page runs:

http://www.pyglet.org/doc/programming_guide/hello_world.html

While unexplored parts of the PyGLet package may yet contain Py2-specific code, 
I'm definitely on my way.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: RE Module Performance

[Steven D'Aprano]

On Thu, 25 Jul 2013 00:34:24 +1000, Chris Angelico wrote:

> But mainly, I'm just wondering how many people here have any basis from
> which to argue the point he's trying to make. I doubt most of us have
> (a) implemented an editor widget, or (b) tested multiple different
> internal representations to learn the true pros and cons of each. And
> even if any of us had, that still wouldn't have any bearing on PEP 393,
> which is about applications, not editor widgets. As stated above, Python
> strings before AND after PEP 393 are poor choices for an editor, ergo
> arguing from that standpoint is pretty useless.

That's a misleading way to put it. Using immutable strings as editor 
buffers might be a bad way to implement all but the most trivial, low-
performance (i.e. slow) editor, but the basic concept of PEP 393, picking 
an internal representation of the text based on its contents, is not. 
That's just normal. The only difference with PEP 393 is that the choice 
is made on the fly, at runtime, instead of decided in advance by the 
programmer.

I expect that the PEP 393 concept of optimizing memory per string buffer 
would work well in an editor. However the internal buffer is arranged, 
you can safely assume that each chunk of text (word, sentence, paragraph, 
buffer...) will very rarely shift from "all Latin 1" to "all BMP" to 
"includes SMP chars". So, for example, entering a SMP character will need 
to immediately up-cast the chunk from 1-byte per char to 4-bytes per 
char, which is relatively pricey, but it's a one-off cost. Down-casting 
when the SMP character is deleted doesn't need to be done immediately, it 
can be performed when the application is idle.

If the chunks are relatively small (say, a paragraph rather than multiple 
pages of text) then even that initial conversion will be invisible. A 
fast touch typist hits a key about every 0.1 of a second; if it takes a 
millisecond to convert the chunk, you wouldn't even notice the delay. You 
can copy and up-cast a lot of bytes in a millisecond.


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

Re: Python 3: dict & dict.keys()

[Steven D'Aprano]

On Wed, 24 Jul 2013 11:31:58 -0700, Ethan Furman wrote:

> On 07/24/2013 10:23 AM, Stefan Behnel wrote:
>> Peter Otten, 24.07.2013 08:23:
>>> Ethan Furman wrote:

 So, my question boils down to:  in Python 3 how is dict.keys()
 different from dict?  What are the use cases?
>>>
>>> To me it looks like views are a solution waiting for a problem.
>>
>> They reduce the API overhead. Previously, you needed values() and
>> itervalues(), with values() being not more than a special case of what
>> itervalues() provides anyway. Now it's just one method that gives you
>> everything. It simply has corrected the tradeoff from two special
>> purpose APIs to one general purpose API, that's all.
> 
> I started this thread for two reasons:
> 
>1) Increase awareness that using `list(dict)` is a cross-version
>replacement for `dict.keys()`
> 
>2) Hopefully learn something about when a view is useful.
> 
> So far #2 is pretty much a failure.

I don't think so.

- viewkeys() can be used as a drop-in replacement for iterkeys(), 
provided you remember not to iterate over it a second time. Doing so 
actually iterates over the view, instead of failing as with the iterator. 
If you actually want a one-shot iterator, call iter() on the view.

- viewkeys() can be used as a drop-in replacement for Python2 keys(), 
provided you only iterate over it once. If you want an actual list, call 
list() on the view.

- Views support set methods which don't modify the set. If there is a non-
modifying set method which is not supported, it probably should be, and 
somebody should raise an enhancement request in the bug tracker. If you 
want an actual independent set you can modify without changing the dict, 
call set() (or frozenset) on the view.

- Views support efficient (O(1) in the case of keys) membership testing, 
which neither iterkeys() nor Python2 keys() does.

- Views support live, read-only access to dict keys and values.



> Only one use-case so far (and it
> feels pretty rare).

Iterating over a dict's values or items is not rare. Using a view is 
better than making a list-copy of the dict and iterating over the list, 
because it avoids copying.

For one-shot iteration, there's no benefit of a view over an iterator, or 
vice versa, but views are useful for more than just one-shot iteration.



> But hey, I have learned that while some set
> operations are allowed (&, ^, |, .isdisjoint()), others are not
> (.remove(), .discard(), .union(), etc.).
> 
> The old .keys(), .values(), and .items() (and their .iter...()
> variations) did something commonly useful.  Of what common use are these
> views?

Everything that dict iteration does, dict views do, and more. So if 
iterkeys() is useful, then so is viewkeys(). Had viewkeys come first, 
iterkeys would never have been invented.

Making an actual list copy of the keys (values, items) is useful, but 
it's not useful enough to dedicate a method (three methods) for it. Just 
call list() on the view (or, in the case of keys, directly on the dict).



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

[ANN] New article in The Python Papers Source Codes - COPADS III (Compendium of Distributions II): Cauchy, Cosine, Exponential, Hypergeometric, Logarithmic, Semicircular, Triangular, and Weibull

[mauricel...@acm.org]

Hi everyone

We have a new article in The Python Papers Source Codes.

Title: COPADS III (Compendium of Distributions II): Cauchy, Cosine, 
Exponential, Hypergeometric, Logarithmic, Semicircular, Triangular, and Weibull

Abstract: This manuscript illustrates the implementation and testing of eight 
statistical distributions, namely Cauchy, Cosine, Exponential, Hypergeometric, 
Logarithmic, Semicircular, Triangular, and Weibull distribution, where each 
distribution consists of three common functions – Probability Density Function 
(PDF), Cumulative Density Function (CDF) and the inverse of CDF (inverseCDF). 
These codes had been incorporated into COPADS codebase 
(https://github.com/copads/ copads) are licensed under Lesser General Public 
Licence version 3.

URL: http://ojs.pythonpapers.org/index.php/tppsc/article/view/253

Maurice Ling
Co-EIC, The Python Papers Source Codes
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: RE Module Performance

[Steven D'Aprano]

On Thu, 25 Jul 2013 04:15:42 +1000, Chris Angelico wrote:

> If nobody had ever thought of doing a multi-format string
> representation, I could well imagine the Python core devs debating
> whether the cost of UTF-32 strings is worth the correctness and
> consistency improvements... and most likely concluding that narrow
> builds get abolished. And if any other language (eg ECMAScript) decides
> to move from UTF-16 to UTF-32, I would wholeheartedly support the move,
> even if it broke code to do so.

Unfortunately, so long as most language designers are European-centric, 
there is going to be a lot of push-back against any attempt to fix (say) 
Javascript, or Java just for the sake of "a bunch of dead languages" in 
the SMPs. Thank goodness for emoji. Wait til the young kids start 
complaining that their emoticons and emoji are broken in Javascript, and 
eventually it will get fixed. It may take a decade, for the young kids to 
grow up and take over Javascript from the old-codgers, but it will happen.


> To my mind, exposing UTF-16 surrogates
> to the application is a bug to be fixed, not a feature to be maintained.

This, times a thousand.

It is *possible* to have non-buggy string routines using UTF-16, but the 
implementation is a lot more complex than most language developers can be 
bothered with. I'm not aware of any language that uses UTF-16 internally 
that doesn't give wrong results for surrogate pairs.



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

Re: Python 3: dict & dict.keys()

[Steven D'Aprano]

On Thu, 25 Jul 2013 16:02:42 +1000, Chris Angelico wrote:

> On Thu, Jul 25, 2013 at 3:48 PM, Steven D'Aprano
>  wrote:
>> Dicts aren't sets, and don't support set methods:
>>
>> py> d1 - d2
>> Traceback (most recent call last):
>>   File "", line 1, in 
>> TypeError: unsupported operand type(s) for -: 'dict' and 'dict'
> 
> I wouldn't take this as particularly significant, though. A future
> version of Python could add that support (and it might well be very
> useful), without breaking any of the effects of views.

I don't think dicts can ever support set methods, since *they aren't 
sets*. Every element consists of both a key and a value, so you have to 
consider both. Set methods are defined in terms of singleton elements, 
not binary elements, so before you even begin, you have to decide what 
does it mean when two elements differ in only one of the two parts?

Given dicts {1: 'a'}, {1: 'b'}, what is the union of them? I can see five 
possibilities:

{1: 'a'}
{1: 'b'}
{1: ['a', 'b']}
{1: set(['a', 'b'])}
Error

Each of the five results may be what you want in some circumstances. It 
would be a stupid thing for dict.union to pick one behaviour and make it 
the One True Way to perform union on two dicts.



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

Re: RE Module Performance

[Chris Angelico]

On Thu, Jul 25, 2013 at 5:02 PM, Steven D'Aprano
 wrote:
> On Thu, 25 Jul 2013 00:34:24 +1000, Chris Angelico wrote:
>
>> But mainly, I'm just wondering how many people here have any basis from
>> which to argue the point he's trying to make. I doubt most of us have
>> (a) implemented an editor widget, or (b) tested multiple different
>> internal representations to learn the true pros and cons of each. And
>> even if any of us had, that still wouldn't have any bearing on PEP 393,
>> which is about applications, not editor widgets. As stated above, Python
>> strings before AND after PEP 393 are poor choices for an editor, ergo
>> arguing from that standpoint is pretty useless.
>
> That's a misleading way to put it. Using immutable strings as editor
> buffers might be a bad way to implement all but the most trivial, low-
> performance (i.e. slow) editor, but the basic concept of PEP 393, picking
> an internal representation of the text based on its contents, is not.
> That's just normal. The only difference with PEP 393 is that the choice
> is made on the fly, at runtime, instead of decided in advance by the
> programmer.

Maybe I worded it poorly, but my point was the same as you're saying
here: that a Python string is a poor buffer for editing, regardless of
PEP 393. It's not that PEP 393 makes Python strings worse for writing
a text editor, it's that immutability does that.

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

Re: RE Module Performance

[Chris Angelico]

On Thu, Jul 25, 2013 at 5:15 PM, Steven D'Aprano
 wrote:
> On Thu, 25 Jul 2013 04:15:42 +1000, Chris Angelico wrote:
>
>> If nobody had ever thought of doing a multi-format string
>> representation, I could well imagine the Python core devs debating
>> whether the cost of UTF-32 strings is worth the correctness and
>> consistency improvements... and most likely concluding that narrow
>> builds get abolished. And if any other language (eg ECMAScript) decides
>> to move from UTF-16 to UTF-32, I would wholeheartedly support the move,
>> even if it broke code to do so.
>
> Unfortunately, so long as most language designers are European-centric,
> there is going to be a lot of push-back against any attempt to fix (say)
> Javascript, or Java just for the sake of "a bunch of dead languages" in
> the SMPs. Thank goodness for emoji. Wait til the young kids start
> complaining that their emoticons and emoji are broken in Javascript, and
> eventually it will get fixed. It may take a decade, for the young kids to
> grow up and take over Javascript from the old-codgers, but it will happen.

I don't know that that'll happen like that. Emoticons aren't broken in
Javascript - you can use them just fine. You only start seeing
problems when you index into that string. People will start to wonder
why, for instance, a "500 character maximum" field deducts two from
the limit when an emoticon goes in. Example:

Type here:
You have 500 characters left (self.value.length).
You have 500 characters left (self.textLength).

function showlimit(self)
{
document.getElementById("limit1").innerHTML=500-self.value.length;
document.getElementById("limit2").innerHTML=500-self.textLength;
}


I've included an attribute documented here[1] as the "codepoint length
of the control's value", but in Chrome on Windows, it still counts
UTF-16 code units. However, I very much doubt that this will result in
language changes. People will just live with it. Chinese and Japanese
users will complain, perhaps, and the developers will write it off as
whinging, and just say "That's what the internet does". Maybe, if
you're really lucky, they'll acknowledge that "that's what JavaScript
does", but even then I doubt it'd result in language changes.

>> To my mind, exposing UTF-16 surrogates
>> to the application is a bug to be fixed, not a feature to be maintained.
>
> This, times a thousand.
>
> It is *possible* to have non-buggy string routines using UTF-16, but the
> implementation is a lot more complex than most language developers can be
> bothered with. I'm not aware of any language that uses UTF-16 internally
> that doesn't give wrong results for surrogate pairs.

The problem isn't the underlying representation, the problem is what
gets exposed to the application. Once you've decided to expose
codepoints to the app (abstracting over your UTF-16 underlying
representation), the change to using UTF-32, or mimicking PEP 393, or
some other structure, is purely internal and an optimization. So I
doubt any language will use UTF-16 internally and UTF-32 to the app.
It'd be needlessly complex.

ChrisA

[1] https://developer.mozilla.org/en-US/docs/Web/API/HTMLTextAreaElement
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3: dict & dict.keys()

[Chris Angelico]

On Thu, Jul 25, 2013 at 5:04 PM, Steven D'Aprano
 wrote:
> - Views support efficient (O(1) in the case of keys) membership testing,
> which neither iterkeys() nor Python2 keys() does.

To save me the trouble and potential error of digging through the
source code: What's the complexity of membership testing on
values/items? Since you're calling it "efficient" it must be better
than O(n) which the list form would be, yet it isn't O(1) or you
wouldn't have qualified "in the case of keys". Does this mean
membership testing of the values and items views is O(log n) in some
way, eg a binary search?

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

Re: Python 3: dict & dict.keys()

[Peter Otten]

Chris Angelico wrote:

> On Thu, Jul 25, 2013 at 5:04 PM, Steven D'Aprano
>  wrote:
>> - Views support efficient (O(1) in the case of keys) membership testing,
>> which neither iterkeys() nor Python2 keys() does.
> 
> To save me the trouble and potential error of digging through the
> source code: What's the complexity of membership testing on
> values/items? Since you're calling it "efficient" it must be better
> than O(n) which the list form would be, yet it isn't O(1) or you
> wouldn't have qualified "in the case of keys". Does this mean
> membership testing of the values and items views is O(log n) in some
> way, eg a binary search?

keys() and items() is O(1); both look up the key in the dictionary and 
items() then proceeds to compare the value. values() is O(n).

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

Re: Python 3: dict & dict.keys()

[Chris Angelico]

On Thu, Jul 25, 2013 at 5:27 PM, Steven D'Aprano
 wrote:
> On Thu, 25 Jul 2013 16:02:42 +1000, Chris Angelico wrote:
>
>> On Thu, Jul 25, 2013 at 3:48 PM, Steven D'Aprano
>>  wrote:
>>> Dicts aren't sets, and don't support set methods:
>>>
>>> py> d1 - d2
>>> Traceback (most recent call last):
>>>   File "", line 1, in 
>>> TypeError: unsupported operand type(s) for -: 'dict' and 'dict'
>>
>> I wouldn't take this as particularly significant, though. A future
>> version of Python could add that support (and it might well be very
>> useful), without breaking any of the effects of views.
>
> I don't think dicts can ever support set methods, since *they aren't
> sets*. Every element consists of both a key and a value, so you have to
> consider both. Set methods are defined in terms of singleton elements,
> not binary elements, so before you even begin, you have to decide what
> does it mean when two elements differ in only one of the two parts?
>
> Given dicts {1: 'a'}, {1: 'b'}, what is the union of them? I can see five
> possibilities:
>
> {1: 'a'}
> {1: 'b'}
> {1: ['a', 'b']}
> {1: set(['a', 'b'])}
> Error
>
> Each of the five results may be what you want in some circumstances. It
> would be a stupid thing for dict.union to pick one behaviour and make it
> the One True Way to perform union on two dicts.

That's true, but we already have that issue with sets. What's the
union of {0} and {0.0}? Python's answer: It depends on the order of
the operands.

>>> i={0}
>>> f={0.0}
>>> i | f
{0}
>>> f | i
{0.0}

I would say that Python can freely pick from the first two options you
offered (either keep-first or keep-last), most likely the first one,
and it'd make good sense. Your third option would be good for a few
specific circumstances, but then you probably would also want the
combination of {1:'a'} and {1:'a'} to be {1:['a','a']} for
consistency. This would make a good utility function, but isn't what
I'd normally see set union doing. Similarly with the fourth option,
though there it's a little more arguable. Raising an error would work,
but is IMO unnecessary.

(Pike has dictionary operations, but has made different choices. For
instance, 0 and 0.0 are considered distinct, so a set can contain
both. Mappings (dicts) merge by keeping the last, not the first. But
the specifics don't much matter.)

A Python set already has to distinguish between object value and
object identity; a dict simply adds a bit more distinction between
otherwise-considered-identical keys, namely their values.

>>> a="This is a test."
>>> b="This is a test."
>>> a is b
False
>>> id(a)
16241512
>>> id(b)
16241392
>>> id(({a}|{b}).pop())
16241512

Assuming a and b have different ids, which is true in the above
example of Py3.3 on Windows, the set union *must* be different from
one of them. Suppose you do a dictionary of id(key) -> value, and a
set of the keys themselves. You could then do set operations on the
keys, and then go and retrieve the values.

Sure, maybe the way of doing things won't be exactly what everyone
expects... but it works, and it makes plausible sense. And as a
theoretical "might be implemented in Python 3.5", it still has no
impact on views, beyond that there are some operations which must be
done with views in <=3.3 that could be done on the dicts themselves in
future.

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

Re: must be dicts in tuple

[Chris Angelico]

On Thu, Jul 25, 2013 at 4:58 PM, Tanaya D  wrote:
> Hi,
>
> I am using Python with Bots(EDI translator)
>
> But i am getting the following error:
> MappingFormatError: must be dicts in tuple: get((({'BOTSID': 'HEADER'},),))

The first thing to do is to construct a short piece of code that
demonstrates the problem. See http://sscce.org/ for some tips. Once
you've done that, run that script and copy and paste its entire output
(which will be your exception traceback) into an email.

That said, though, I believe the problem you're seeing is going to be
Bots-specific. You'll possibly do better on a Bots mailing list rather
than a general Python one.

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

Re: RE Module Performance

[Steven D'Aprano]

On Thu, 25 Jul 2013 17:58:10 +1000, Chris Angelico wrote:

> On Thu, Jul 25, 2013 at 5:15 PM, Steven D'Aprano
>  wrote:
>> On Thu, 25 Jul 2013 04:15:42 +1000, Chris Angelico wrote:
>>
>>> If nobody had ever thought of doing a multi-format string
>>> representation, I could well imagine the Python core devs debating
>>> whether the cost of UTF-32 strings is worth the correctness and
>>> consistency improvements... and most likely concluding that narrow
>>> builds get abolished. And if any other language (eg ECMAScript)
>>> decides to move from UTF-16 to UTF-32, I would wholeheartedly support
>>> the move, even if it broke code to do so.
>>
>> Unfortunately, so long as most language designers are European-centric,
>> there is going to be a lot of push-back against any attempt to fix
>> (say) Javascript, or Java just for the sake of "a bunch of dead
>> languages" in the SMPs. Thank goodness for emoji. Wait til the young
>> kids start complaining that their emoticons and emoji are broken in
>> Javascript, and eventually it will get fixed. It may take a decade, for
>> the young kids to grow up and take over Javascript from the
>> old-codgers, but it will happen.
> 
> I don't know that that'll happen like that. Emoticons aren't broken in
> Javascript - you can use them just fine. You only start seeing problems
> when you index into that string. People will start to wonder why, for
> instance, a "500 character maximum" field deducts two from the limit
> when an emoticon goes in.

I get that. I meant *Javascript developers*, not end-users. The young 
kids today who become Javascript developers tomorrow will grow up in a 
world where they expect to be able to write band names like
"▼□■□■□■" (yes, really, I didn't make that one up) and have it just work.
Okay, all those characters are in the BMP, but emoji aren't, and I 
guarantee that even as we speak some new hipster band is trying to decide 
whether to name themselves "Smiling 😢" or "Crying 😊".

:-)



>> It is *possible* to have non-buggy string routines using UTF-16, but
>> the implementation is a lot more complex than most language developers
>> can be bothered with. I'm not aware of any language that uses UTF-16
>> internally that doesn't give wrong results for surrogate pairs.
> 
> The problem isn't the underlying representation, the problem is what
> gets exposed to the application. Once you've decided to expose
> codepoints to the app (abstracting over your UTF-16 underlying
> representation), the change to using UTF-32, or mimicking PEP 393, or
> some other structure, is purely internal and an optimization. So I doubt
> any language will use UTF-16 internally and UTF-32 to the app. It'd be
> needlessly complex.

To be honest, I don't understand what you are trying to say.

What I'm trying to say is that it is possible to use UTF-16 internally, 
but *not* assume that every code point (character) is represented by a 
single 2-byte unit. For example, the len() of a UTF-16 string should not 
be calculated by counting the number of bytes and dividing by two. You 
actually need to walk the string, inspecting each double-byte:

# calculate length
count = 0
inside_surrogate = False
for bb in buffer:  # get two bytes at a time
if is_lower_surrogate(bb):
inside_surrogate = True
continue
if is_upper_surrogate(bb):
if inside_surrogate:
count += 1
inside_surrogate = False
continue
raise ValueError("missing lower surrogate")
if inside_surrogate:
break
count += 1
if inside_surrogate:
raise ValueError("missing upper surrogate")


Given immutable strings, you could validate the string once, on creation, 
and from then on assume they are well-formed:

# calculate length, assuming the string is well-formed:
count = 0
skip = False
for bb in buffer:  # get two bytes at a time
if skip:
count += 1
skip = False
continue
if is_surrogate(bb):
skip = True
count += 1


String operations such as slicing become much more complex once you can 
no longer assume a 1:1 relationship between code points and code units, 
whether they are 1, 2 or 4 bytes. Most (all?) language developers don't 
handle that complexity, and push responsibility for it back onto the 
coder using the language. 



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

Re: RE Module Performance

[wxjmfauth]

Le mercredi 24 juillet 2013 16:47:36 UTC+2, Michael Torrie a écrit :
> On 07/24/2013 07:40 AM, wxjmfa...@gmail.com wrote:
> 
> > Sorry, you are not understanding Unicode. What is a Unicode
> 
> > Transformation Format (UTF), what is the goal of a UTF and
> 
> > why it is important for an implementation to work with a UTF.
> 
> 
> 
> Really?  Enlighten me.
> 
> 
> 
> Personally, I would never use UTF as a representation *in memory* for a
> 
> unicode string if it were up to me.  Why?  Because UTF characters are
> 
> not uniform in byte width so accessing positions within the string is
> 
> terribly slow and has to always be done by starting at the beginning of
> 
> the string.  That's at minimum O(n) compared to FSR's O(1).  Surely you
> 
> understand this.  Do you dispute this fact?
> 
> 
> 
> UTF is a great choice for interchange, though, and indeed that's what it
> 
> was designed for.
> 
> 
> 
> Are you calling for UTF to be adopted as the internal, in-memory
> 
> representation of unicode?  Or would you simply settle for UCS-4?
> 
> Please be clear here.  What are you saying?
> 
> 
> 
> > Short example. Writing an editor with something like the
> 
> > FSR is simply impossible (properly).
> 
> 
> 
> How? FSR is just an implementation detail.  It could be UCS-4 and it
> 
> would also work.

-

A coding scheme works with a unique set of characters (the repertoire),
and the implementation (the programming) works with a unique set
of encoded code points. The critical step is the path
{unique set of characters} <--> {unique set of encoded code points}


Fact: there is no other way to do it properly (This is explaining
why we have to live today with all these coding schemes or also
explaining why so many coding schemes hadto be created).

How to understand it? With a sheet of paper and a pencil.

In the byte string world, this step is a no-op.

In Unicode, it is exactly the purpose of a "utf" to achieve this
step. "utf": a confusing name covering at the same time the
process and the result of the process.
A "utf chunk", a series of bits (not bytes), hold intrisically
the information about the character it is representing.

Other "exotic" coding schemes like iso6937 of "CID-fonts" are woking
in the same way.

"Unicode" with the help of "utf(s)" does not differ from the basic
rule.

-

ucs-2: ucs-2 is a perfecly and correctly working coding scheme.
ucs-2 is not different from the other coding schemes and does
not behave differently (cp... or iso-... or ...). It only
covers a smaller repertoire.

-

utf32: as a pointed many times. You are already using it (maybe
without knowing it). Where? in fonts (OpenType technology),
rendering engines, pdf files. Why? Because there is not other
way to do it better.

--

The Unicode table (its constuction) is a problem per se.
It is not a technical problem, a very important "linguistic
aspect" of Unicode.
See https://groups.google.com/forum/#!topic/comp.lang.python/XkTKE7U8CS0

--

If you are not understanding my "editor" analogy. One other
proposed exercise. Build/create a flexible iso-8859-X coding
scheme. You will quickly understand where the bottleneck
is.
Two working ways:
- stupidly with an editor and your fingers.
- lazily with a sheet of paper and you head.




About my benchmarks: No offense. You are not understanding them,
because you do not understand what this FSR does and the coding
of characters. It's a little bit a devil's circle.

Conceptually, this FSR is spending its time in solving the
problem it creates itsself, with plenty of side effects.

-

There is a clear difference between FSR and ucs-4/utf32.

-

See also:
http://www.unicode.org/reports/tr17/

(In my mind, quite "dry" and not easy to understand at
a first reading).


jmf


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

Re: Python 3: dict & dict.keys()

[Steven D'Aprano]

On Thu, 25 Jul 2013 18:15:22 +1000, Chris Angelico wrote:

> On Thu, Jul 25, 2013 at 5:27 PM, Steven D'Aprano
>  wrote:
>> On Thu, 25 Jul 2013 16:02:42 +1000, Chris Angelico wrote:
>>
>>> On Thu, Jul 25, 2013 at 3:48 PM, Steven D'Aprano
>>>  wrote:
 Dicts aren't sets, and don't support set methods:

 py> d1 - d2
 Traceback (most recent call last):
   File "", line 1, in 
 TypeError: unsupported operand type(s) for -: 'dict' and 'dict'
>>>
>>> I wouldn't take this as particularly significant, though. A future
>>> version of Python could add that support (and it might well be very
>>> useful), without breaking any of the effects of views.
>>
>> I don't think dicts can ever support set methods, since *they aren't
>> sets*. Every element consists of both a key and a value, so you have to
>> consider both. Set methods are defined in terms of singleton elements,
>> not binary elements, so before you even begin, you have to decide what
>> does it mean when two elements differ in only one of the two parts?
>>
>> Given dicts {1: 'a'}, {1: 'b'}, what is the union of them? I can see
>> five possibilities:
>>
>> {1: 'a'}
>> {1: 'b'}
>> {1: ['a', 'b']}
>> {1: set(['a', 'b'])}
>> Error
>>
>> Each of the five results may be what you want in some circumstances. It
>> would be a stupid thing for dict.union to pick one behaviour and make
>> it the One True Way to perform union on two dicts.
> 
> That's true, but we already have that issue with sets. What's the union
> of {0} and {0.0}? Python's answer: It depends on the order of the
> operands.

That's a side-effect of how numeric equality works in Python. Since 0 == 
0.0, you can't have both as keys in the same dict, or set. Indeed, the 
same numeric equality issue occurs here:

py> from fractions import Fraction
py> [0, 2.5] == [0.0, Fraction(5, 2)]
True

So nothing really to do with sets or dicts specifically. 

Aside: I think the contrary behaviour is, well, contrary. It would be 
strange and disturbing to do this:

for key in some_dict:
if key == 0:
print("found")
print(some_dict[key])

and have the loop print "found" and then have the key lookup fail, but 
apparently that's how things work in Pike :-(


> I would say that Python can freely pick from the first two options you
> offered (either keep-first or keep-last), most likely the first one, and
> it'd make good sense. Your third option would be good for a few specific
> circumstances, but then you probably would also want the combination of
> {1:'a'} and {1:'a'} to be {1:['a','a']} for consistency.

Okay, that's six variations. And no, I don't think the "consistency" 
argument is right -- the idea is that you can have multiple values per 
key. Since 'a' == 'a', that's only one value, not two.

The variation using a list, versus the set, depends on whether you care 
about order or hashability.


[...]
> Raising an error would work, but is IMO unnecessary.

I believe that's the only reasonable way for a dict union method to work. 
As the Zen says:

In the face of ambiguity, refuse the temptation to guess.

Since there is ambiguity which value should be associated with the key, 
don't guess.


[...]
> A Python set already has to distinguish between object value and object
> identity; a dict simply adds a bit more distinction between
> otherwise-considered-identical keys, namely their values.

Object identity is a red herring. It would be perfectly valid for a 
Python implementation to create new instances of each element in the set 
union, assuming such creation was free of side-effects (apart from memory 
usage and time, naturally). set.union() makes no promise about the 
identity of elements, and it is defined the same way for languages where 
object identity does not exist (say, old-school Pascal).


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

Re: RE Module Performance

[Chris Angelico]

On Thu, Jul 25, 2013 at 7:22 PM, Steven D'Aprano
 wrote:
> What I'm trying to say is that it is possible to use UTF-16 internally,
> but *not* assume that every code point (character) is represented by a
> single 2-byte unit. For example, the len() of a UTF-16 string should not
> be calculated by counting the number of bytes and dividing by two. You
> actually need to walk the string, inspecting each double-byte

Anything's possible. But since underlying representations can be
changed fairly easily (relative term of course - it's a lot of work,
but it can be changed in a single release, no deprecation required or
anything), there's very little reason to continue using UTF-16
underneath. May as well switch to UTF-32 for convenience, or PEP 393
for convenience and efficiency, or maybe some other system that's
still mostly fixed-width.

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

Re: RE Module Performance

[Chris Angelico]

On Thu, Jul 25, 2013 at 7:27 PM,   wrote:
> A coding scheme works with a unique set of characters (the repertoire),
> and the implementation (the programming) works with a unique set
> of encoded code points. The critical step is the path
> {unique set of characters} <--> {unique set of encoded code points}

That's called Unicode. It maps the character 'A' to the code point
U+0041 and so on. Code points are integers. In fact, they are very
well represented in Python that way (also in Pike, fwiw):

>>> ord('A')
65
>>> chr(65)
'A'
>>> chr(123456)
'\U0001e240'
>>> ord(_)
123456

> In the byte string world, this step is a no-op.
>
> In Unicode, it is exactly the purpose of a "utf" to achieve this
> step. "utf": a confusing name covering at the same time the
> process and the result of the process.
> A "utf chunk", a series of bits (not bytes), hold intrisically
> the information about the character it is representing.

No, now you're looking at another level: how to store codepoints in
memory. That demands that they be stored as bits and bytes, because PC
memory works that way.

> utf32: as a pointed many times. You are already using it (maybe
> without knowing it). Where? in fonts (OpenType technology),
> rendering engines, pdf files. Why? Because there is not other
> way to do it better.

And UTF-32 is an excellent system... as long as you're okay with
spending four bytes for every character.

> See https://groups.google.com/forum/#!topic/comp.lang.python/XkTKE7U8CS0

I refuse to click this link. Give us a link to the
python-list@python.org archive, or gmane, or something else more
suited to the audience. I'm not going to Google Groups just to figure
out what you're saying.

> If you are not understanding my "editor" analogy. One other
> proposed exercise. Build/create a flexible iso-8859-X coding
> scheme. You will quickly understand where the bottleneck
> is.
> Two working ways:
> - stupidly with an editor and your fingers.
> - lazily with a sheet of paper and you head.

What has this to do with the editor?

> There is a clear difference between FSR and ucs-4/utf32.

Yes. Memory usage. PEP 393 strings might take up half or even a
quarter of what they'd take up in fixed UTF-32. Other than that,
there's no difference.

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

Re: Python 3: dict & dict.keys()

[Chris Angelico]

On Thu, Jul 25, 2013 at 7:44 PM, Steven D'Aprano
 wrote:
> On Thu, 25 Jul 2013 18:15:22 +1000, Chris Angelico wrote:
>> That's true, but we already have that issue with sets. What's the union
>> of {0} and {0.0}? Python's answer: It depends on the order of the
>> operands.
>
> That's a side-effect of how numeric equality works in Python. Since 0 ==
> 0.0, you can't have both as keys in the same dict, or set. Indeed, the
> same numeric equality issue occurs here:
>
> py> from fractions import Fraction
> py> [0, 2.5] == [0.0, Fraction(5, 2)]
> True
>
> So nothing really to do with sets or dicts specifically.

Here's how I imagine set/dict union:
1) Take a copy of the first object
2) Iterate through the second. If the key doesn't exist in the result, add it.

This works just fine even when "add it" means "store this value
against this key". The dict's value and the object's identity are both
ignored, and you simply take the first one you find.

> Aside: I think the contrary behaviour is, well, contrary. It would be
> strange and disturbing to do this:
>
> for key in some_dict:
> if key == 0:
> print("found")
> print(some_dict[key])
>
> and have the loop print "found" and then have the key lookup fail, but
> apparently that's how things work in Pike :-(

I agree, that would be very strange and disturbing. I mentioned that
aspect merely in passing, but the reason for the difference is not an
oddity of key lookup, but a different decision about float and int: in
Pike, 0 and 0.0 are not equal. (Nor are 1 and 1.0, in case you thought
this was a weirdness of zero.) It's a debatable point; are we trying
to say that all numeric types represent real numbers, and are equal if
they represent the same real number? Or are different representations
distinct, just as much as the string "0" is different from the integer
0? Pike took the latter approach. PHP took the former approach to its
illogical extreme, that the string "0001E1" is equal to "10" (both
strings). No, the dictionary definitely needs to use object equality
to do its lookup, although I could well imagine an implementation that
runs orders of magnitude faster when object identity can be used.

>> I would say that Python can freely pick from the first two options you
>> offered (either keep-first or keep-last), most likely the first one, and
>> it'd make good sense. Your third option would be good for a few specific
>> circumstances, but then you probably would also want the combination of
>> {1:'a'} and {1:'a'} to be {1:['a','a']} for consistency.
>
> Okay, that's six variations. And no, I don't think the "consistency"
> argument is right -- the idea is that you can have multiple values per
> key. Since 'a' == 'a', that's only one value, not two.

Well, it depends what you're doing with the merging of the dicts. But
all of these extra ways to do things would be explicitly-named
functions with much rarer usage (and quite possibly not part of the
standard library, they'd be snippets shared around and put directly in
application code).

>> Raising an error would work, but is IMO unnecessary.
>
> I believe that's the only reasonable way for a dict union method to work.
> As the Zen says:
>
> In the face of ambiguity, refuse the temptation to guess.
>
> Since there is ambiguity which value should be associated with the key,
> don't guess.

There's already ambiguity as to which of two equal values should be
retained by the set. Python takes the first. Is that guessing? Is that
violating the zen? I don't see a problem with the current set
implementation, and I also don't see a problem with using that for
dict merging.

> Object identity is a red herring. It would be perfectly valid for a
> Python implementation to create new instances of each element in the set
> union, assuming such creation was free of side-effects (apart from memory
> usage and time, naturally). set.union() makes no promise about the
> identity of elements, and it is defined the same way for languages where
> object identity does not exist (say, old-school Pascal).

That still doesn't deal with the "which type should the new object
be". We're back to this question: What is the union of 0 and 0.0?

>>> {0} | {0.0}
{0}
>>> {0.0} | {0}
{0.0}

Maybe Python could create a brand new object, but would it be an int
or a float? The only way I could imagine this working is with a
modified-set class that takes an object constructor, and passes every
object through it. That way, you could have set(float) that coerces
everything to float on entry, which would enforce what you're saying
(even down to potentially creating a new object with a new id, though
float() seems to return a float argument unchanged in CPython 3.3).
Would that really help anything, though? Do we gain anything by not
simply accepting, in the manner of Colonel Fairfax, the first that
comes?

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

Critic my module

[Devyn Collier Johnson]

Aloha Python Users!

   I made a Python3 module that allows users to use certain Linux shell 
commands from Python3 more easily than using os.system(), 
subprocess.Popen(), or subprocess.getoutput(). This module (once placed 
with the other modules) can be used like this


import boash; boash.ls()

   I attached the module. I plan to release it on the Internet soon, 
but feel free to use it now. It is licensed under LGPLv3.


   The name comes from combining "Boa" with "SHell". Notice that the 
module's name almost looks like "BASH", a common Linux shell. The Boa is 
a constrictor snake. This module makes Unix shells easier to use via 
Python3. This brings the system shell closer to the Python shell.



Mahalo,

Devyn Collier Johnson
devyncjohn...@gmail.com
#!/usr/bin/python3
#Made by Devyn Collier Johnson, NCLA, Linux+, LPIC-1, DCTS
#Made using the Geany IDE
#LGPLv3
import re, sys, subprocess, platform
def grep(regex,textf):
#Sample Command: grep.grep("^x",dir())
#Syntax: boash.grep(regexp_string,list_of_strings_to_search)
version = '0.2a'
expr = re.compile(regex)
match = re.findall(expr, textf)
if match != None:
print(match)
def ls():
version = '0.3'
print(subprocess.getoutput('ls'))
def dir():
version = '0.3'
print(subprocess.getoutput('dir'))
def ll():
version = '0.3'
print(subprocess.getoutput('ls -l'))
def vdir():
version = '0.3'
print(subprocess.getoutput('ls -l'))
def uname():
version = '0.3'
print(platform.uname())
def cmd(*arg):
version = '0.3'
print(subprocess.getoutput(arg))
def command(*arg):
version = '0.3'
print(subprocess.getoutput(arg))
def man(x):
version = '0.3'
print(subprocess.getoutput('man' + x))
def apropos(*arg):
version = '0.3'
print(subprocess.getoutput('apropos' + arg))
def bash(*arg):
version = '0.3'
print(subprocess.getoutput(arg))
def shell(*arg):
version = '0.3'
print(subprocess.getoutput(arg))
def clear_bash_history():
version = '0.3'
print(subprocess.getoutput('history -c'))
def clear_bash_hist():
version = '0.3'
print(subprocess.getoutput('history -c'))
def clear_hist():
version = '0.3'
print(subprocess.getoutput('history -c'))
def clear_history():
version = '0.3'
print(subprocess.getoutput('history -c'))
def del_bash_hist():
version = '0.3'
print(subprocess.getoutput('history -c'))
def delete_bash_hist():
version = '0.3'
print(subprocess.getoutput('history -c'))
def del_hist():
version = '0.3'
print(subprocess.getoutput('history -c'))
def delete_history():
version = '0.3'
print(subprocess.getoutput('history -c'))
def delete_bash_history():
version = '0.3'
print(subprocess.getoutput('history -c'))
def delete_hist():
version = '0.3'
print(subprocess.getoutput('history -c'))
def firefox():
version = '0.3'
print(subprocess.Popen('(firefox &)'))
def opera():
version = '0.3'
print(subprocess.Popen('(opera &)'))
def arora():
version = '0.3'
print(subprocess.Popen('(arora &)'))
def dolphin():
version = '0.3'
print(subprocess.Popen('(dolphin &)'))
def nautilus():
version = '0.3'
print(subprocess.Popen('(nautilus &)'))
def konqueror():
version = '0.3'
print(subprocess.Popen('(konqueror &)'))
def smplayer():
version = '0.3'
print(subprocess.Popen('(smplayer &)'))
def mplayer():
version = '0.3'
print(subprocess.Popen('(mplayer &)'))
def vlc():
version = '0.3'
print(subprocess.Popen('(vlc &)'))
def qvlc():
version = '0.3'
print(subprocess.Popen('(qvlc &)'))
def nvlc():
version = '0.3'
jprint(subprocess.Popen('(nvlc &)'))
def svlc():
version = '0.3'
print(subprocess.Popen('(svlc &)'))
def rvlc():
version = '0.3'
print(subprocess.Popen('(rvlc &)'))
def xterm():
version = '0.3'
print(subprocess.Popen('(xterm &)'))
def geany():
version = '0.3'
print(subprocess.Popen('(geany &)'))
def lsof():
version = '0.3'
print(subprocess.getoutput(lsof))
def free(*arg):
version = '0.3'
print(subprocess.getoutput('free' + arg))
def lsof(*arg):
version = '0.3'
print(subprocess.getoutput('lsof' + arg))
def pwd():
version = '0.3'
print(subprocess.getoutput('pwd'))
def getcwd():
version = '0.3'
print(subprocess.getoutput('pwd'))
def whoami():
version = '0.3'
print(subprocess.getoutput('whoami'))
def finger():
version = '0.3'
print(subprocess.getoutput('finger'))
def hostname():
version = '0.3'
print(subprocess.getoutput('hostname'))
def arch():
version = '0.3'

Re: Python 3: dict & dict.keys()

[Johannes Bauer]

On 25.07.2013 07:48, Steven D'Aprano wrote:

> Then you aren't looking very closely. d.keys() returns a set-like view 
> into the dict, which is great for comparing elements:
> 
> py> d1 = dict.fromkeys([1, 2, 3, 4])
> py> d2 = dict.fromkeys([3, 4, 5, 6])
> py> d1.keys() & d2.keys()  # keys that are in both
> {3, 4}
> py> d1.keys() ^ d2.keys()  # keys not in both
> {1, 2, 5, 6}
> py> d1.keys() - d2.keys()  # keys only in d1
> {1, 2}
> py> d2.keys() - d1.keys()  # keys only in d2
> {5, 6}

I know this is completely off-topic, but I really must thank you for
showing that neat trick. I didn't know set()'s operators &, ^, - were
overloaded (and always used difference/intersection, etc). That's
really, really neat.

Thanks again,
Joe

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyGLet on Python 3

[Devyn Collier Johnson]

On 07/23/2013 02:24 AM, John Ladasky wrote:

On 07/21/2013 08:10 PM, Joseph Clark wrote:

John, have you taken a look at pyglet?  It's an alternative to pygame and I 
found it pretty slick once I got the hang of it.  There is a development 
version that's compatible with python 3 and I've never had a bug with it.  It 
wraps OpenGL itself so there are no additional dependencies.


// joseph w. clark , phd , visiting research associate
\\ university of nebraska at omaha - college of IS&T
  

Hi Joe,

Thanks for the PyGLet recommendation.  I like OpenGL.  Unfortunately, I can't seem to get 
PyGLet to work, even though the pyglet.org front page claims that "the major 
1.2alpha1 release brings pyglet to Python 3."

I followed the links to this page:

https://code.google.com/p/pyglet/downloads/list?q=1.2alpha1

I installed pyglet on my Linux system's Python 3.3 using distutils, as I have 
done with many other packages.  But I can't run test.py, nor can I even get as 
far as importing pyglet from my Python 3.3 interpreter command line.  The 
obstacle is apparently Python 2.x-style print statements, which are found 
throughout tests.py and pyglet/__init__.py.

Does anyone know an efficient way around this problem?  Thanks!
I cannot get Pyglet to work. I successfully installed the module and it 
imports successfully, but a previously suggested command does not work. 
I use Python3.


>>> import pyglet
>>> pyglet.media.load('./boot.ogg', streaming=False).play()
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'module' object has no attribute 'media'

Mahalo,

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

Re: RE Module Performance

[Jeremy Sanders]

wxjmfa...@gmail.com wrote:

> Short example. Writing an editor with something like the
> FSR is simply impossible (properly).

http://www.gnu.org/software/emacs/manual/html_node/elisp/Text-Representations.html#Text-Representations

"To conserve memory, Emacs does not hold fixed-length 22-bit numbers that are 
codepoints of text characters within buffers and strings. Rather, Emacs uses a 
variable-length internal representation of characters, that stores each 
character as a sequence of 1 to 5 8-bit bytes, depending on the magnitude of 
its codepoint[1]. For example, any ASCII character takes up only 1 byte, a 
Latin-1 character takes up 2 bytes, etc. We call this representation of text 
multibyte.

...

[1] This internal representation is based on one of the encodings defined by 
the Unicode Standard, called UTF-8, for representing any Unicode codepoint, but 
Emacs extends UTF-8 to represent the additional codepoints it uses for raw 8-
bit bytes and characters not unified with Unicode.

"

Jeremy


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

Python Script Hashplings

[Devyn Collier Johnson]

If I execute a Python3 script with this haspling (#!/usr/bin/python3.3) 
and Python3.3 is not installed, but Python3.2 is installed, would the 
script still work? Would it fall back to Python3.2?


I hope Dihedral is listening. I would like to see another response from HIM.

Mahalo,

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

Cross-Platform Python3 Equivalent to notify-send

[Devyn Collier Johnson]

Linux systems with the proper software can use the "notify-send" 
command. Is there a cross-platform Python3 equivalent?


Mahalo,

Devyn Collier Johnson
devyncjohn...@gmail.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: RE Module Performance

[Devyn Collier Johnson]

On 07/25/2013 09:36 AM, Jeremy Sanders wrote:

wxjmfa...@gmail.com wrote:


Short example. Writing an editor with something like the
FSR is simply impossible (properly).

http://www.gnu.org/software/emacs/manual/html_node/elisp/Text-Representations.html#Text-Representations

"To conserve memory, Emacs does not hold fixed-length 22-bit numbers that are
codepoints of text characters within buffers and strings. Rather, Emacs uses a
variable-length internal representation of characters, that stores each
character as a sequence of 1 to 5 8-bit bytes, depending on the magnitude of
its codepoint[1]. For example, any ASCII character takes up only 1 byte, a
Latin-1 character takes up 2 bytes, etc. We call this representation of text
multibyte.

...

[1] This internal representation is based on one of the encodings defined by
the Unicode Standard, called UTF-8, for representing any Unicode codepoint, but
Emacs extends UTF-8 to represent the additional codepoints it uses for raw 8-
bit bytes and characters not unified with Unicode.

"

Jeremy


Wow! The thread that I started has changed a lot and lived a long time. 
I look forward to its first birthday (^u^).


Devyn Collier Johnson
--
http://mail.python.org/mailman/listinfo/python-list

virtualenv problem

[D. Xenakis]

Hi there.
Im using windows 7 64bit
I have installed python 3.3.2 in C:\Python33
and then easy_install , pip, and virtualenv.
But i do not know if the virtualenv installation is correct as i cant seem to 
be able to create any virtual enviroment yet.

How can i check if everything is correct? What exactly should i do to create a 
virtual enviroment into my new_project folder located here: in C:\new_project ?
I think there is something wrong with the installation because when i run 
through idle the virtual-env scripts located in "C:\Python33\Scripts" then i 
get the following..

Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:06:53) [MSC v.1600 64 bit 
(AMD64)] on win32
Type "copyright", "credits" or "license()" for more information.
>>>  RESTART 
>>> 
You must provide a DEST_DIR
Usage: virtualenv-3.3-script.py [OPTIONS] DEST_DIR

Options:
  --version show program's version number and exit
  -h, --helpshow this help message and exit
  -v, --verbose Increase verbosity
  -q, --quiet   Decrease verbosity
  -p PYTHON_EXE, --python=PYTHON_EXE
The Python interpreter to use, e.g.,
--python=python2.5 will use the python2.5 interpreter
to create the new environment.  The default is the
interpreter that virtualenv was installed with
(C:\Python33\pythonw.exe)
  --clear   Clear out the non-root install and start from scratch
  --no-site-packagesDon't give access to the global site-packages dir to
the virtual environment (default)
  --system-site-packages
Give access to the global site-packages dir to the
virtual environment
  --always-copy Always copy files rather than symlinking
  --unzip-setuptoolsUnzip Setuptools when installing it
  --relocatable Make an EXISTING virtualenv environment relocatable.
This fixes up scripts and makes all .pth files
relative
  --no-setuptools   Do not install setuptools (or pip) in the new
virtualenv.
  --no-pip  Do not install pip in the new virtualenv.
  --extra-search-dir=SEARCH_DIRS
Directory to look for setuptools/pip distributions in.
You can add any number of additional --extra-search-
dir paths.
  --never-download  Never download anything from the network. This is now
always the case. The option is only retained for
backward compatibility, and does nothing. Virtualenv
will fail if local distributions of setuptools/pip are
not present.
  --prompt=PROMPT   Provides an alternative prompt prefix for this
environment
  --setuptools  Backward compatibility. Does nothing.
  --distribute  Backward compatibility. Does nothing.
Traceback (most recent call last):
  File "C:\Python33\Scripts\virtualenv-3.3-script.py", line 9, in 
load_entry_point('virtualenv==1.10', 'console_scripts', 'virtualenv-3.3')()
  File "C:\Python33\lib\site-packages\virtualenv.py", line 786, in main
sys.exit(2)
SystemExit: 2


plz any help appreciated
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Script Hashplings

[MRAB]

On 25/07/2013 14:42, Devyn Collier Johnson wrote:

If I execute a Python3 script with this haspling (#!/usr/bin/python3.3)
and Python3.3 is not installed, but Python3.2 is installed, would the
script still work? Would it fall back to Python3.2?


Why don't you try it?


I hope Dihedral is listening. I would like to see another response from HIM.



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

Re: Python Script Hashplings

[Matthew Lefavor]

The answer is "probably not." If you just want to use the latest version of
Python 3 you have installed on your system, use: "#!/usr/bin/python3". When
you use the specific minor version numbers, they point to that specific
minor version.

Actually, the preferred shebang line is of the form: "#!/usr/bin/env
python3". This way the end users can override the interpreter with, say, a
virtualenv, rather than being stuck with the system default.


On Thu, Jul 25, 2013 at 9:54 AM, MRAB  wrote:

> On 25/07/2013 14:42, Devyn Collier Johnson wrote:
>
>> If I execute a Python3 script with this haspling (#!/usr/bin/python3.3)
>> and Python3.3 is not installed, but Python3.2 is installed, would the
>> script still work? Would it fall back to Python3.2?
>>
>>  Why don't you try it?
>
>
>  I hope Dihedral is listening. I would like to see another response from
>> HIM.
>>
>>
> --
> http://mail.python.org/**mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Critic my module

[Joshua Landau]

On 25 July 2013 14:24, Devyn Collier Johnson wrote:

> Aloha Python Users!
>
>I made a Python3 module that allows users to use certain Linux shell
> commands from Python3 more easily than using os.system(),
> subprocess.Popen(), or subprocess.getoutput(). This module (once placed
> with the other modules) can be used like this
>
> import boash; boash.ls()
>
>I attached the module. I plan to release it on the Internet soon, but
> feel free to use it now. It is licensed under LGPLv3.
>
>The name comes from combining "Boa" with "SHell". Notice that the
> module's name almost looks like "BASH", a common Linux shell. The Boa is a
> constrictor snake. This module makes Unix shells easier to use via Python3.
> This brings the system shell closer to the Python shell.
>

1) Have you tested everything? At first glance some of those look like they
won't work.

2) Whenever you repeat yourself, *especially* at this magnitude, you're
doing something seriously wrong - *especially* in Python.

*Completely-untestedly-and-super-quick-hackedly:*

import re, sys, subprocess, platform
class Command:
def __init__(self, command=None):
 self.command = command
def __call__(self, *args):
command_list = [self.command] if self.command else []
 command_list.extend(args)
print(subprocess.getoutput([command_list]))
def uname():
 print(platform.uname())
def lsof():
print(subprocess.getoutput(lsof))
apropos   = Command("apropos")
arora = Command("(arora &)")
dir   = Command("dir")
dolphin   = Command("(dolphin &)")
env   = Command("env")
finger= Command("finger")
firefox   = Command("(firefox &)")
free  = Command("free")
geany = Command("(geany &)")
getcwd= Command("pwd")
go_back   = Command("cd !!:1")
halt  = Command("shutdown -h now")
hostname  = Command("hostname")
konqueror = Command("(konqueror &)")
ls= Command("ls")
lsof  = Command("lsof")
man   = Command("man")
mplayer   = Command("(mplayer &)")
nautilus  = Command("(nautilus &)")
nvlc  = Command("(nvlc &)")
opera = Command("(opera &)")
pwd   = Command("pwd")
qvlc  = Command("(qvlc &)")
repeat= Command("!")
runlevel  = Command("runlevel")
rvlc  = Command("(rvlc &)")
smplayer  = Command("(smplayer &)")
svlc  = Command("(svlc &)")
vlc   = Command("(vlc &)")
whoami= Command("whoami")
xterm = Command("(xterm &)")
arch = architecture = Command("arch")
bash = cmd = command = shell = Command()
last_cmd = last_command = repeat_cmd = Command("!!")
ll = vdir = Command("ls - l")
no_login = no_logins = nologin = nologins = Command("shutdown -k now")
power_down = power_off = powerdown = poweroff = Command("shutdown -P now")
reboot = restart = Command("shutdown -r now")
shut_down = shutdown = Command("shutdown now")
clear_bash_hist = clear_bash_history = clear_hist = clear_history = \
del_bash_hist = del_hist = delete_bash_hist = delete_bash_history = \
 delete_hist = delete_history = Command("history -c")
ejcd = ejdvd = eject_cd = eject_cdrom = eject_disc = eject_disc_tray = \
eject_dvd = eject_tray = ejectcd = ejectcdrom =
 ejectdisc = ejectdisctray = ejectdvd = ejecttray = ejtray = Command("eject
cdrom1")



I wouldn't actually do it like this (I'd probably start with a dict and add
to a class programmatically), but this is a simple display of how one can
use classes and other meta-constructs to make things look nicer. It also
doesn't deal with forcing the number of arguments to be correct, but this
is demo material and so I leave that to you.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Critic my module

[Alain Ketterlin]

Devyn Collier Johnson  writes:

>I made a Python3 module that allows users to use certain Linux
> shell commands from Python3 more easily than using os.system(),
> subprocess.Popen(), or subprocess.getoutput(). This module (once
> placed with the other modules) can be used like this

Good, but I doubt it's really useful: I think nobody is going to add a
dependency on your module for, basically, one-line wrappers...

Here are a few comments:

> def ls():
>   version = '0.3'
>   print(subprocess.getoutput('ls'))

version is local here, so basically your first statement is useless
(search for "global" in python's language ref).

> def uname():
>   version = '0.3'
>   print(platform.uname())

I once learned: "never print anything in a library function". This is a
bad thing to do, for a variety of reasons. For instance, stdout may be
redirected during this call...

> def man(x):
>   version = '0.3'
>   print(subprocess.getoutput('man' + x))

getoutput is (essentially) Popen(...,shell=True), and the doc says:

"the use of shell=True is strongly discouraged in cases where the
command string is constructed from external input"

(for very good reasons)

> def clear_bash_history():
>   version = '0.3'
>   print(subprocess.getoutput('history -c'))

Who told you subprocess will use bash? Again, the doc:

"On Unix with shell=True, the shell defaults to /bin/sh."

All your uses of bash-isms may break (esp. "!!")

> def firefox():
>   version = '0.3'
>   print(subprocess.Popen('(firefox &)'))

See section "Replacing the os.spawn family" in... the doc.

> def go_back():
>   version = '0.3'
>   print(subprocess.Popen('cd !!:1'))

Hopeless. Have you tried this?

> def reboot():
>   version = '0.3'
>   print(subprocess.Popen('shutdown -r now'))

What do you expect this to print? I mean, after shutdown/reboot.

> version = '0.6b'

So, what's the version? 0.3 or 0.6b

(btw, are you sure this "version" is the same as the one you use in all
functions?).

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

Re: Critic my module

[Schneider]

Hi,

nice idea.

mybe -  for security reasons - you should ensure, that the right tool is 
called and not some tool put the path with the same name.


bg,
Johannes

On Thu 25 Jul 2013 03:24:30 PM CEST, Devyn Collier Johnson wrote:

Aloha Python Users!

   I made a Python3 module that allows users to use certain Linux
shell commands from Python3 more easily than using os.system(),
subprocess.Popen(), or subprocess.getoutput(). This module (once
placed with the other modules) can be used like this

import boash; boash.ls()

   I attached the module. I plan to release it on the Internet soon,
but feel free to use it now. It is licensed under LGPLv3.

   The name comes from combining "Boa" with "SHell". Notice that the
module's name almost looks like "BASH", a common Linux shell. The Boa
is a constrictor snake. This module makes Unix shells easier to use
via Python3. This brings the system shell closer to the Python shell.


Mahalo,

Devyn Collier Johnson
devyncjohn...@gmail.com






--
GLOBE Development GmbH
Königsberger Strasse 260
48157 MünsterGLOBE Development GmbH
Königsberger Strasse 260
48157 Münster
0251/5205 390
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3: dict & dict.keys()

[Ethan Furman]

On 07/24/2013 11:01 PM, alex23 wrote:

On 25/07/2013 4:31 AM, Ethan Furman wrote:

   2) Hopefully learn something about when a view is useful.


I haven't seeen this mentioned - forgive me if it's a repeat - but views are 
constant references to whichever set they
represent.

Python 2.7:


dd = dict(a=1,b=2,c=3)
keys = dd.keys()
'a' in keys

True

dd['d'] = 4
'd' in keys

False

Python 3.3:

dd = dict(a=1,b=2,c=3)
keys = dd.keys()
'a' in keys

True

dd['d'] = 4
'd' in keys

True

If part of my code is only interested in what keys or values are present, it 
doesn't need to be given a reference to the
full dictionary, just to whichever view it cares about.


In these cases why is a view better than just using the dict?  Is it a safety 
so the you don't accidentally modify the dict?

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

Re: Python3, GUIs, game APIs, PyGLet, 2to3...?

[Kushal Kumaran]

John Ladasky  writes:

> Followup to my own post: I've made progress with PyGLet.  I should mention 
> that I'm using Ubuntu Linux 13.04 64-bit, in case it matters.
>
> I tried executing "2to3 -w *.py" on just the files in the directory 
> pyglet-1.2alpha1/pyglet.  I then changed back to the pyglet-1.2alpha1 
> directory, and executed "sudo python setup.py install".  Finally, I started 
> my Python3 interpreter.  This time, "import pyglet" generated no errors.
>

Does your python command mean python2 or python3?  The setup.py at
https://code.google.com/p/pyglet/source/browse/setup.py seems to run
2to3 automatically, but that will only happen if you actually use
python3 to run setup.py.

> The PyGLet "Hello, World" code found on this web page runs:
>
> http://www.pyglet.org/doc/programming_guide/hello_world.html
>
> While unexplored parts of the PyGLet package may yet contain Py2-specific 
> code, I'm definitely on my way.

-- 
regards,
kushal
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3: dict & dict.keys()

[Ethan Furman]

On 07/24/2013 10:48 PM, Steven D'Aprano wrote:

On Wed, 24 Jul 2013 08:57:11 -0700, Ethan Furman wrote:


My point is that in 2.x .keys() did something different from the dict,
while in 3.x it appears to me that they are the same.


Then you aren't looking very closely.


Actually, I am.  That's why I started this thread.

Thank you for the insights.

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

Re: Python 3: dict & dict.keys()

[Steven D'Aprano]

On Thu, 25 Jul 2013 20:34:23 +1000, Chris Angelico wrote:

> On Thu, Jul 25, 2013 at 7:44 PM, Steven D'Aprano
>  wrote:
>> On Thu, 25 Jul 2013 18:15:22 +1000, Chris Angelico wrote:
>>> That's true, but we already have that issue with sets. What's the
>>> union of {0} and {0.0}? Python's answer: It depends on the order of
>>> the operands.
>>
>> That's a side-effect of how numeric equality works in Python. Since 0
>> == 0.0, you can't have both as keys in the same dict, or set. Indeed,
>> the same numeric equality issue occurs here:
>>
>> py> from fractions import Fraction
>> py> [0, 2.5] == [0.0, Fraction(5, 2)] True
>>
>> So nothing really to do with sets or dicts specifically.
> 
> Here's how I imagine set/dict union:
> 1) Take a copy of the first object
> 2) Iterate through the second. If the key doesn't exist in the result,
> add it.

That's because you're too much of a programmer to step away from the 
implementation. Fundamentally, set union has nothing to do with objects, 
or bit strings, or any concrete implementation. Sets might be infinite, 
and "take a copy" impossible or meaningless.

Logically, the union of set A and set B is the set containing every 
element which is in A, every element in B, and no element which is not. 
How you assemble those elements in a concrete implementation is, in a 
sense, irrelevant. In old-school Pascal, the universe of possible 
elements is taken from the 16-bit, or 32-bit if you're lucky, integers; 
in Python, it's taken from hashable objects. Even using your suggested 
algorithm above, since union is symmetric, it should make no difference 
whether you start with the first, or with the second.


> This works just fine even when "add it" means "store this value against
> this key". The dict's value and the object's identity are both ignored,
> and you simply take the first one you find.

I don't believe that "works", since the whole point of dicts is to store 
the values. In practice, the values are more important than the keys. The 
key only exists so you can get to the value -- the key is equivalent to 
the index in a list, the value to the value at that index. We normally 
end up doing something like "print adict[key]", not "print key". So 
throwing away the values just because they happen to have the same key is 
a fairly dubious thing to do, at least for union or intersection.

(In contrast, that's exactly what you want an update method to do. 
Different behaviour for different methods.)


[...]
>>> Raising an error would work, but is IMO unnecessary.
>>
>> I believe that's the only reasonable way for a dict union method to
>> work. As the Zen says:
>>
>> In the face of ambiguity, refuse the temptation to guess.
>>
>> Since there is ambiguity which value should be associated with the key,
>> don't guess.
> 
> There's already ambiguity as to which of two equal values should be
> retained by the set. 

In an ideal world of Platonic Ideals, it wouldn't matter, since 
everything is equal to itself, and to nothing else. There's only one 
number "two", whether you write it as 2 or 2.0 or 800/400 or Ⅱ or 0b10, 
and it is *impossible even in principle* to distinguish them since there 
is no "them" to distinguish between. Things that are equal shouldn't be 
distinguishable, not by value, not by type, not by identity.

But that would be *too abstract* to be useful, and so we allow some of 
the abstractness leak away, to the benefit of all. But the consequence of 
this is that we sometimes have to make hard decisions, like, which one of 
these various "twos" do we want to keep? Or more often, we stumble into a 
decision by allowing the implementation specify the behaviour, rather 
than choosing the behaviour and the finding an implementation to match 
it. Given the two behaviours:

{2} | {2.0} => {2} or {2.0}, which should it be? Why not Fraction(2) or 
Decimal(2) or 2+0j?

there's no reason to prefer Python's answer, "the value on the left", 
except that it simplifies the implementation. The union operator ought to 
be symmetrical, a ∪ b should be identical to b ∪ a, but isn't. Another 
leaky abstraction.


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

Re: Python 3: dict & dict.keys()

[Chris Angelico]

On Fri, Jul 26, 2013 at 12:57 AM, Steven D'Aprano
 wrote:
> [ snip lengthy explanation of sets ]
> The union operator ought to
> be symmetrical, a ∪ b should be identical to b ∪ a, but isn't. Another
> leaky abstraction.

Right. I agree with all your theory, which is fine and good. If we had
a "set of real numbers", then each one would be both equal to and
indistinguishable from any other representation of itself. But Python
doesn't work with real numbers. It works with ints and floats and
Fractions and Decimals and Guido-knows-what. (Sorry, I don't normally
talk like that, but the expression begged to be said. :) )

So since Python already lets its abstraction leak a bit for
usefulness, why not retain the exact same leak when working with a
dict? A set is a dict with no values... a dict is a set with extra
payload. They're given very similar literal notation; if they were
meant to be more distinct, why was no alternative symbol used?

(I love how a random side comment can become a topic of its own.)

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

Is it that easy to install Python ?

[santiago . diez]

Hi there,

I never write any Python program but as a system administrator, I'm often asked 
to install python on Debian servers.

I just finished downloading, configuring, making and installing.

The binary is now installed in :
/usr/local/Python-2.7.5/bin/python2.7
(the path is a deliberate administrator choice).

Is that it?

What else will my users need?

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

Re: RE Module Performance

[Steven D'Aprano]

On Thu, 25 Jul 2013 14:36:25 +0100, Jeremy Sanders wrote:

> wxjmfa...@gmail.com wrote:
> 
>> Short example. Writing an editor with something like the FSR is simply
>> impossible (properly).
> 
> http://www.gnu.org/software/emacs/manual/html_node/elisp/Text-
Representations.html#Text-Representations
> 
> "To conserve memory, Emacs does not hold fixed-length 22-bit numbers
> that are codepoints of text characters within buffers and strings.
> Rather, Emacs uses a variable-length internal representation of
> characters, that stores each character as a sequence of 1 to 5 8-bit
> bytes, depending on the magnitude of its codepoint[1]. For example, any
> ASCII character takes up only 1 byte, a Latin-1 character takes up 2
> bytes, etc. We call this representation of text multibyte.

Well, you've just proven what Vim users have always suspected: Emacs 
doesn't really exist.


> [1] This internal representation is based on one of the encodings
> defined by the Unicode Standard, called UTF-8, for representing any
> Unicode codepoint, but Emacs extends UTF-8 to represent the additional
> codepoints it uses for raw 8- bit bytes and characters not unified with
> Unicode.
> "

Do you know what those characters not unified with Unicode are? Is there 
a list somewhere? I've read all of the pages from here to no avail:

http://www.gnu.org/software/emacs/manual/html_node/elisp/Non_002dASCII-Characters.html



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

Re: RE Module Performance

[Chris Angelico]

On Fri, Jul 26, 2013 at 1:26 AM, Steven D'Aprano
 wrote:
> On Thu, 25 Jul 2013 14:36:25 +0100, Jeremy Sanders wrote:
>> "To conserve memory, Emacs does not hold fixed-length 22-bit numbers
>> that are codepoints of text characters within buffers and strings.
>> Rather, Emacs uses a variable-length internal representation of
>> characters, that stores each character as a sequence of 1 to 5 8-bit
>> bytes, depending on the magnitude of its codepoint[1]. For example, any
>> ASCII character takes up only 1 byte, a Latin-1 character takes up 2
>> bytes, etc. We call this representation of text multibyte.
>
> Well, you've just proven what Vim users have always suspected: Emacs
> doesn't really exist.

... lolwut?

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

Re: How to tick checkboxes with the same name?

[malayrev]

вторник, 23 июля 2013 г., 9:05:14 UTC+4 пользователь Joel Goldstick написал:
> On Tue, Jul 23, 2013 at 12:10 AM,   wrote:
> 
> > I faced a problem: to implement appropriate search program I need to tick 
> > few checkboxes which turned out to have the same name (name="a", 
> > id="a1","a2","a3","a4"). Set_input('a', True) does not work (I use Grab 
> > library), this command leads to the error "checkboxgroup must be set to a 
> > sequence". I don't understand what the sequence actually is, so I'm stuck 
> > with how to tick the checkboxes. It would be really great if someone would 
> > help me with how to handle this question. The code is available here:
> 
> > view-source:http://zakupki.gov.ru/pgz/public/action/contracts/search/ext/enter
> 
> > --
> 
> > http://mail.python.org/mailman/listinfo/python-list
> 
> 
> 
> Have you tried a[0], a[1], etc. for the names?
> 
> 
> 
> --
> 
> Joel Goldstick
> 
> http://joelgoldstick.com

sure, I tried, doesn't work
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to tick checkboxes with the same name?

[malayrev]

вторник, 23 июля 2013 г., 11:25:00 UTC+4 пользователь Peter Otten написал:
> malay...@gmail.com wrote:
> 
> 
> 
> > I faced a problem: to implement appropriate search program I need to tick
> 
> > few checkboxes which turned out to have the same name (name="a",
> 
> > id="a1","a2","a3","a4"). Set_input('a', True) does not work (I use Grab
> 
> > library), 
> 
> 
> 
> For all but the most popular projects a url works wonders. I'm assuming 
> 
> 
> 
> http://grablib.org
> 
> 
> 
> > this command leads to the error "checkboxgroup must be set to a
> 
> > sequence". I don't understand what the sequence actually is, so I'm stuck
> 
> > with how to tick the checkboxes. 
> 
> 
> 
> If I were to guess:
> 
> 
> 
> set_input("a", [True, True, True, True])
> 
> 
> 
> but I don't see that form documented on page
> 
> 
> 
> http://docs.grablib.org/api/ext_form.html
> 
> 
> 
> If it doesn't work try
> 
> 
> 
> set_input_by_id(_"a1", True)
> 
> set_input_by_id(_"a2", True)
> 
> 
> 
> and so on.

Well, I have read the documentation, I guess the problem lies in somewhat 
different field. As long as I understand it refers to Checkboxgroup classes. As 
checkboxes of interest belong to some common group with the common name "a", 
they do have values different from "True" or "False" (probably a sequence?) and 
I should guess somehow what are the real ones. How to do this?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3: dict & dict.keys()

[Ian Kelly]

On Thu, Jul 25, 2013 at 2:13 AM, Peter Otten <__pete...@web.de> wrote:
> Chris Angelico wrote:
>
>> On Thu, Jul 25, 2013 at 5:04 PM, Steven D'Aprano
>>  wrote:
>>> - Views support efficient (O(1) in the case of keys) membership testing,
>>> which neither iterkeys() nor Python2 keys() does.
>>
>> To save me the trouble and potential error of digging through the
>> source code: What's the complexity of membership testing on
>> values/items? Since you're calling it "efficient" it must be better
>> than O(n) which the list form would be, yet it isn't O(1) or you
>> wouldn't have qualified "in the case of keys". Does this mean
>> membership testing of the values and items views is O(log n) in some
>> way, eg a binary search?
>
> keys() and items() is O(1); both look up the key in the dictionary and
> items() then proceeds to compare the value. values() is O(n).

3.x values() is O(n) but avoids the unnecessary step of copying all the
values in the dict that you get when performing the same operation
using 2.x values().  Hence, although the asymptotic complexity is the
same, it's still more efficient.
-- 
http://mail.python.org/mailman/listinfo/python-list

Creating a Simple User Interface for a Function

[CTSB01]

I have the following code that runs perfectly: 

 def psi_j(x, j):
  rtn = []
  for n2 in range(0, len(x) * j - 2):
n = n2 / j
r = n2 - n * j
rtn.append(j * x[n] + r * (x[n + 1] - x[n]))
print 'n2 =', n2, ': n =', n, ' r =' , r, ' rtn =', rtn
  return rtn

This code takes a string x = [0,1,1,1,2] for example (it must always begin with 
0) and a parameter j, say 2, and outputs a string (x = [0, 1, 2, 2, 2, 2, 2, 3] 
in this example).

It does this in two steps: First it decomposes some number m into a multiple of 
j and a remainder.  Then it runs this decomposition through a function on the 
rtn.append line.  

Notice that this has cj - 1 terms where c is the number of terms in the input 
string and j is the parameter.  Normally, we would like it to be able to 
calculate cj terms.  This is an issue with the function that I am more than 
happy to put aside for the moment.

My key interest is to be able to make this program usable for someone who has 
no knowledge of programming.  In particular, I need some kind of user interface 
that prompts the user to input a string (ideally just by putting in numbers in 
the form 011123334 for example) and a parameter, and then displays the output 
sequence.  This is essentially what the program already does but the idea is to 
make it usable for even the most technologically disinclined.  Ideally it would 
do this without needing to run Python at all.  If anyone is able to make this 
happen in Python I would be eternally grateful. 
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Python 3: dict & dict.keys()

[Prasad, Ramit]

Terry Reedy wrote:
> 
> On 7/24/2013 4:34 PM, Prasad, Ramit wrote:
> 
> > I am still not clear on the advantage of views vs. iterators.
> 
> A1: Views are iterables that can be iterated more than once. Therefore,
> they can be passed to a function that re-iterates its inputs, or to
> multiple functions. They support 'x in view' as efficiently as possible.
> Think about how you would write the non-view equivalent of '(0,None) in
> somedict.views())'. When set-like, views support some set operations.
> For .keys, which are always set-like, these operations are easy to
> implement as dicts are based on a hashed array of keys.

Hmm, that is a change that makes some sense to me. Does the view
get updated when dictionary changes or is a new view needed? I 
assume the latter.  

> 
> Q2: What is the advantage of views vs. lists?
> 
> A2: They do not take up space that is not needed. They can be converted
> to lists, to get all the features of lists, but not vice versa.
> 
> > What makes d.viewkeys() better than d.iterkeys()? Why did they decide
> > not to rename d.iterkeys() to d.keys() and instead use d.viewkeys()?
> 
> This is historically the wrong way to phrase the question. The 2.7
> .viewxyz methods were *not* used to make the 3.x .xyz methods. It was
> the other way around. 3.0 came out with view methods replacing both list
> and iter methods just after 2.6, after a couple of years of design, and
> a year and a half before 2.7. The view methods were backported from 3.1
> to 2.7, with 'view' added to the name to avoid name conflicts, to make
> it easier to write code that would either run on both 2.7 and 3.x or be
> converted with 2to3.
> 
> A better question is: 'When 3.0 was designed, why were views invented
> for the .xyz methods rather than just renaming the .iterxyz methods. The
> advantages given above are the answer. View methods replace both list
> and iterator methods and are more flexible than either and directly or
> indirectly have all the advantages of both.
> 
> My question is why some people are fussing so much because Python
> developers gave them one thing that is better than either of the two
> things it replaces?

I personally am not "fussing" as existing functionality was preserved
(and improved). I just was not clear on the difference. Thanks for
all the detail and context.

> 
> The mis-phrased question above illustrates why people new to Python
> should use the latest 3.x and ignore 2.x unless they must use 2.x
> libraries. 2.7 has all the old stuff, for back compatibility, and as
> much of the new stuff in 3.1 as seemed sensible, for forward
> compatibility. Thus it has lots of confusing duplication, and in this
> case, triplication

I work with 2.6 so no choice there... :)

> 
> --
> Terry Jan Reedy
> 
> --
> http://mail.python.org/mailman/listinfo/python-list

This email is confidential and subject to important disclaimers and conditions 
including on offers for the purchase or sale of securities, accuracy and 
completeness of information, viruses, confidentiality, legal privilege, and 
legal entity disclaimers, available at 
http://www.jpmorgan.com/pages/disclosures/email.  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is it that easy to install Python ?

[Maarten]

On Thursday, July 25, 2013 5:11:15 PM UTC+2, santia...@caoba.fr wrote:
> Hi there,
> 
> I never write any Python program but as a system administrator, I'm often 
> asked to install python on Debian servers.
> 
> I just finished downloading, configuring, making and installing.
> 
> The binary is now installed in :
> /usr/local/Python-2.7.5/bin/python2.7
> (the path is a deliberate administrator choice).
> 
> Is that it?

Probably.

> What else will my users need?

The path must be search $PATH in the environment where Python is used, so that 
standard scripts starting with "#!/usr/bin/env python" will find your python.

Next your users will probably start requesting additional packages (regex, 
lxml, numpy, scipy, matplotlib, ... depending on what they actually do).

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

Re: Is it that easy to install Python ?

[Matthew Lefavor]

On Thu, Jul 25, 2013 at 11:11 AM,  wrote:

> Hi there,
>
> I never write any Python program but as a system administrator, I'm often
> asked to install python on Debian servers.
>
> I just finished downloading, configuring, making and installing.
>
> The binary is now installed in :
> /usr/local/Python-2.7.5/bin/python2.7
> (the path is a deliberate administrator choice).
>
> Is that it?
>
> What else will my users need?
>
They may need permission to install third-party modules themselves. That
would probably require write permissions to /usr/local/Python-2.7.5/lib. If
you are unwilling to grant those permissions, you can suggest that they
learn how to work with "virtualenvs" (http://www.virtualenv.org/en/latest/),
which would allow them to install third-party modules locally.

And, of course, they need to be saavy enough to put the new python
installation on the PATH.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3: dict & dict.keys()

[Peter Otten]

Ian Kelly wrote:

> On Thu, Jul 25, 2013 at 2:13 AM, Peter Otten <__pete...@web.de> wrote:
>> Chris Angelico wrote:
>>
>>> On Thu, Jul 25, 2013 at 5:04 PM, Steven D'Aprano
>>>  wrote:
 - Views support efficient (O(1) in the case of keys) membership
 testing, which neither iterkeys() nor Python2 keys() does.
>>>
>>> To save me the trouble and potential error of digging through the
>>> source code: What's the complexity of membership testing on
>>> values/items? Since you're calling it "efficient" it must be better
>>> than O(n) which the list form would be, yet it isn't O(1) or you
>>> wouldn't have qualified "in the case of keys". Does this mean
>>> membership testing of the values and items views is O(log n) in some
>>> way, eg a binary search?
>>
>> keys() and items() is O(1); both look up the key in the dictionary and
>> items() then proceeds to compare the value. values() is O(n).
> 
> 3.x values() is O(n) but avoids the unnecessary step of copying all the
> values in the dict that you get when performing the same operation
> using 2.x values().  Hence, although the asymptotic complexity is the
> same, it's still more efficient.

In Python 2 the prudent pythonista used itervalues() to avoid unnecessary 
intermediate list...

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

Re: Understanding other people's code

[Azureaus]

On Friday, July 12, 2013 3:22:59 PM UTC+1, Azureaus wrote:
> Hi all,
> 
> I've been asked to take over a project from someone else and to extend the 
> functionality of this. The project is written in Python which I haven't had 
> any real experience with (although I do really like it) so I've spent the 
> last week or two settling in, trying to get my head around Python and the way 
> in which this code works.
> 
> 
> 
> The problem is the code was clearly written by someone who is exceptionally 
> good and seems to inherit everything from everywhere else. It all seems very 
> dynamic, nothing is written statically except in some configuration files. 
> 
> Basically the problem is I am new to the language and this was clearly 
> written by someone who at the moment is far better at it than I am!
> 
> 
> 
> I'm starting to get pretty worried about my lack of overall progress and so I 
> wondered if anyone out there had some tips and techniques for understanding 
> other peoples code. There has to be 10/15 different scripts with at least 10 
> functions in each file I would say.
> 
> 
> 
> Literally any idea will help, pen and paper, printing off all the code and 
> doing some sort of highlighting session - anything! I keep reading bits of 
> code and thinking "well where the hell has that been defined and what does it 
> mean" to find it was inherited from 3 modules up the chain. I really need to 
> get a handle on how exactly all this slots together! Any techniques,tricks or 
> methodologies that people find useful would be much appreciated.

Thank you to everyone who replied constructively, the various suggestions all 
helped a lot. I'd like to suggest to anyone who reads this in the future who is 
in a similar situation to do as David Chess suggested and install eclipse with 
pydev. Although I prefer to use Sublime to actually write code, Eclipse turned 
out to be invaluable in helping me jump around and understand the code 
especially how things were passed around) and for debugging things over the 
last few days. Success!
Cheers everyone.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3: dict & dict.keys()

[Ethan Furman]

On 07/25/2013 09:11 AM, Prasad, Ramit wrote:

Terry Reedy wrote:


On 7/24/2013 4:34 PM, Prasad, Ramit wrote:


I am still not clear on the advantage of views vs. iterators.


A1: Views are iterables that can be iterated more than once. Therefore,
they can be passed to a function that re-iterates its inputs, or to
multiple functions. They support 'x in view' as efficiently as possible.
Think about how you would write the non-view equivalent of '(0,None) in
somedict.views())'. When set-like, views support some set operations.
For .keys, which are always set-like, these operations are easy to
implement as dicts are based on a hashed array of keys.


Hmm, that is a change that makes some sense to me. Does the view
get updated when dictionary changes or is a new view needed? I
assume the latter.


Nope, the former.  That is a big advantage that the views have over concrete lists: they show the /current/ state, and 
so are always up-do-date.


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

Re: Is it that easy to install Python ?

[Irmen de Jong]

On 25-7-2013 17:11, santiago.d...@caoba.fr wrote:
> Hi there,
> 
> I never write any Python program but as a system administrator, I'm often 
> asked to install python on Debian servers.
> 
> I just finished downloading, configuring, making and installing.
> 
> The binary is now installed in :
> /usr/local/Python-2.7.5/bin/python2.7
> (the path is a deliberate administrator choice).
> 
> Is that it?
> 
> What else will my users need?

Why didn't you use the Debian package instead? You now have installed an 
unsupported,
untested custom built Python version on your server. Why not simply

$ apt-get install python

and let the Debian package maintainers take care of properly testing and 
supporting
it... Also, installing additional python packages will be much less of a hassle 
because
there's hundreds of them readily available in Debian's package repositories and 
they can
be installed (including correct dependencies) in the same way.


Irmen

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

Re: Is it that easy to install Python ?

[Chris Angelico]

On Fri, Jul 26, 2013 at 2:36 AM, Irmen de Jong  wrote:
> On 25-7-2013 17:11, santiago.d...@caoba.fr wrote:
>> Hi there,
>>
>> I never write any Python program but as a system administrator, I'm often 
>> asked to install python on Debian servers.
>>
>> I just finished downloading, configuring, making and installing.
>>
>> The binary is now installed in :
>> /usr/local/Python-2.7.5/bin/python2.7
>> (the path is a deliberate administrator choice).
>>
> Why didn't you use the Debian package instead? You now have installed an 
> unsupported,
> untested custom built Python version on your server. Why not simply
>
> $ apt-get install python

That'll do fine on Debian 7 (Wheezy, current stable). On Debian 6
(Squeeze, oldstable), that'll get you a 2.6 release IIRC.

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

Re: RE Module Performance

[Steven D'Aprano]

On Fri, 26 Jul 2013 01:36:07 +1000, Chris Angelico wrote:

> On Fri, Jul 26, 2013 at 1:26 AM, Steven D'Aprano
>  wrote:
>> On Thu, 25 Jul 2013 14:36:25 +0100, Jeremy Sanders wrote:
>>> "To conserve memory, Emacs does not hold fixed-length 22-bit numbers
>>> that are codepoints of text characters within buffers and strings.
>>> Rather, Emacs uses a variable-length internal representation of
>>> characters, that stores each character as a sequence of 1 to 5 8-bit
>>> bytes, depending on the magnitude of its codepoint[1]. For example,
>>> any ASCII character takes up only 1 byte, a Latin-1 character takes up
>>> 2 bytes, etc. We call this representation of text multibyte.
>>
>> Well, you've just proven what Vim users have always suspected: Emacs
>> doesn't really exist.
> 
> ... lolwut?


JMF has explained that it is impossible, impossible I say!, to write an 
editor using a flexible string representation. Since Emacs uses such a 
flexible string representation, Emacs is impossible, and therefore Emacs 
doesn't exist.

QED.



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

Re: RE Module Performance

[Chris Angelico]

On Fri, Jul 26, 2013 at 3:18 AM, Steven D'Aprano
 wrote:
> On Fri, 26 Jul 2013 01:36:07 +1000, Chris Angelico wrote:
>
>> On Fri, Jul 26, 2013 at 1:26 AM, Steven D'Aprano
>>  wrote:
>>> On Thu, 25 Jul 2013 14:36:25 +0100, Jeremy Sanders wrote:
 "To conserve memory, Emacs does not hold fixed-length 22-bit numbers
 that are codepoints of text characters within buffers and strings.
 Rather, Emacs uses a variable-length internal representation of
 characters, that stores each character as a sequence of 1 to 5 8-bit
 bytes, depending on the magnitude of its codepoint[1]. For example,
 any ASCII character takes up only 1 byte, a Latin-1 character takes up
 2 bytes, etc. We call this representation of text multibyte.
>>>
>>> Well, you've just proven what Vim users have always suspected: Emacs
>>> doesn't really exist.
>>
>> ... lolwut?
>
>
> JMF has explained that it is impossible, impossible I say!, to write an
> editor using a flexible string representation. Since Emacs uses such a
> flexible string representation, Emacs is impossible, and therefore Emacs
> doesn't exist.
>
> QED.

Quad Error Demonstrated.

I never got past the level of Canis Latinicus in debating class.

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

Re: how: embed + extend to control my running app?

[David M. Cotter]

Okay the link problem was solved: i had installed a 64bit python and my app is 
32bit.

i'm using ActivePython installer from here:
http://www.activestate.com/activepython/downloads

it seems that now the problem is that this does not install the _d versions of 
the .lib.   :(

does anyone know how to get or create the _d version of the .lib out of the 
ActivePtyon installation?
-- 
http://mail.python.org/mailman/listinfo/python-list

Problem with PyObjC and NSEvents

[kle]

Hello all,

I am having a rather specialized problem involving PyObjC and receiving 
NSEvents, and I'm wondering whether anybody here might have any insight. 

I'm writing a Python program, using PyObjC, that runs in the background and 
registers whenever the user clicks the mouse, in any application.

I do this using an NSEvents global events monitor:

NSEvent.addGlobalMonitorForEventsMatchingMask_handler_(NSLeftMouseDownMask, 
handler)

where "handler" is the name of my handler method.

The code works fine when I run the .py file from the command line -- my handler 
method is called whenever I click the mouse, and everything happens as expected.

However, when I bundle it into a standalone app (using py2app) and run it, the 
app fails to register clicks. I have gotten it to work intermittently -- 
sometimes it will start working after the app has been brought to the front for 
the first time. But for the most part, it doesn't register the clicks at all.

Any ideas on what I might try to get it working? I am not sure whether this is 
an NSEvents problem or a PyObjC problem, or just a me being stupid problem. But 
any help or guidance would be greatly appreciated. 

Thanks,

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

Re: Is it that easy to install Python ?

[Grant Edwards]

On 2013-07-25, santiago.d...@caoba.fr  wrote:
> Hi there,
>
> I never write any Python program but as a system administrator, I'm
> often asked to install python on Debian servers.

Are you sure it's not already installed?  I haven't seen a Linux
distro for a _long_ time that didn't include Python as part of the
base installation.

> I just finished downloading, configuring, making and installing.
>
> The binary is now installed in :
> /usr/local/Python-2.7.5/bin/python2.7

Why not just apt-get install python?

-- 
Grant Edwards   grant.b.edwardsYow! Uh-oh!!  I'm having
  at   TOO MUCH FUN!!
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3: dict & dict.keys()

[Terry Reedy]

On 7/25/2013 12:21 PM, Ethan Furman wrote:

On 07/25/2013 09:11 AM, Prasad, Ramit wrote:



Hmm, that is a change that makes some sense to me. Does the view
get updated when dictionary changes or is a new view needed? I
assume the latter.


Nope, the former.  That is a big advantage that the views have over
concrete lists: they show the /current/ state, and so are always
up-do-date.


I think 'view' is generally used in CS to mean a live view, as opposed 
to a snapshot. Memoryviews in 3.x are also live views. Dictionary views 
are read-only. I believe memoryviews can be read-write if allowed by the 
object being viewed.


Python slices are snapshots. It has been proposed that they should be 
views to avoid copying memory, but that has been rejected since views 
necessarily keep the underlying object alive. Instead, applications can 
define the views they need. (They might, for instance, allow multiple 
slices in a view, as tk Text widgets do.)


--
Terry Jan Reedy

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

Re: RE Module Performance

[wxjmfauth]

Le jeudi 25 juillet 2013 12:14:46 UTC+2, Chris Angelico a écrit :
> On Thu, Jul 25, 2013 at 7:27 PM,   wrote:
> 
> > A coding scheme works with a unique set of characters (the repertoire),
> 
> > and the implementation (the programming) works with a unique set
> 
> > of encoded code points. The critical step is the path
> 
> > {unique set of characters} <--> {unique set of encoded code points}
> 
> 
> 
> That's called Unicode. It maps the character 'A' to the code point
> 
> U+0041 and so on. Code points are integers. In fact, they are very
> 
> well represented in Python that way (also in Pike, fwiw):
> 
> 
> 
> >>> ord('A')
> 
> 65
> 
> >>> chr(65)
> 
> 'A'
> 
> >>> chr(123456)
> 
> '\U0001e240'
> 
> >>> ord(_)
> 
> 123456
> 
> 
> 
> > In the byte string world, this step is a no-op.
> 
> >
> 
> > In Unicode, it is exactly the purpose of a "utf" to achieve this
> 
> > step. "utf": a confusing name covering at the same time the
> 
> > process and the result of the process.
> 
> > A "utf chunk", a series of bits (not bytes), hold intrisically
> 
> > the information about the character it is representing.
> 
> 
> 
> No, now you're looking at another level: how to store codepoints in
> 
> memory. That demands that they be stored as bits and bytes, because PC
> 
> memory works that way.
> 
> 
> 
> > utf32: as a pointed many times. You are already using it (maybe
> 
> > without knowing it). Where? in fonts (OpenType technology),
> 
> > rendering engines, pdf files. Why? Because there is not other
> 
> > way to do it better.
> 
> 
> 
> And UTF-32 is an excellent system... as long as you're okay with
> 
> spending four bytes for every character.
> 
> 
> 
> > See https://groups.google.com/forum/#!topic/comp.lang.python/XkTKE7U8CS0
> 
> 
> 
> I refuse to click this link. Give us a link to the
> 
> python-list@python.org archive, or gmane, or something else more
> 
> suited to the audience. I'm not going to Google Groups just to figure
> 
> out what you're saying.
> 
> 
> 
> > If you are not understanding my "editor" analogy. One other
> 
> > proposed exercise. Build/create a flexible iso-8859-X coding
> 
> > scheme. You will quickly understand where the bottleneck
> 
> > is.
> 
> > Two working ways:
> 
> > - stupidly with an editor and your fingers.
> 
> > - lazily with a sheet of paper and you head.
> 
> 
> 
> What has this to do with the editor?
> 
> 
> 
> > There is a clear difference between FSR and ucs-4/utf32.
> 
> 
> 
> Yes. Memory usage. PEP 393 strings might take up half or even a
> 
> quarter of what they'd take up in fixed UTF-32. Other than that,
> 
> there's no difference.
> 
> 
> 
> ChrisA




Let start with a simple string \textemdash or \texttendash

>>> sys.getsizeof('–')
40
>>> sys.getsizeof('a')
26

jmf

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

Re: Creating a Simple User Interface for a Function

[Dave Angel]

On 07/25/2013 12:03 PM, CTSB01 wrote:

I have the following code that runs perfectly:

  def psi_j(x, j):
   rtn = []
   for n2 in range(0, len(x) * j - 2):
 n = n2 / j
 r = n2 - n * j
 rtn.append(j * x[n] + r * (x[n + 1] - x[n]))
 print 'n2 =', n2, ': n =', n, ' r =' , r, ' rtn =', rtn
   return rtn



No it doesn't run perfectly.  It'll get a syntax error on the print 
function call.  That's assuming you're still using Python 3.3.  You 
really need to start by specifying your environment, without making us 
look back through previous threads from you.




This code takes a string x = [0,1,1,1,2] for example


That's not a string.  A string would be like
   xx = psi_j("0abcd1234")

Perhaps you mean list?  And is it a list of integers, or of arbitrary 
numbers?  Are there any constraints on the sizes or signs of those numbers?



(it must always begin with 0) and a parameter j, say 2, and outputs a string (x 
= [0, 1, 2, 2, 2, 2, 2, 3] in this example).

It does this in two steps: First it decomposes some number m into a multiple of 
j and a remainder.


Only if you replace the / with //.  Or just use the function divmod():
  n, r = divmod(n2, m)



 Then it runs this decomposition through a function on the rtn.append line.

Notice that this has cj - 1 terms where c is the number of terms in the input 
string and j is the parameter.  Normally, we would like it to be able to 
calculate cj terms.
This is an issue with the function that I am more than happy to put aside for 
the moment.

My key interest is to be able to make this program


So far you have a function, not a program.  If you put it in a text file 
and run it from python, it'll do nothing but display a syntax error 
message.  And when you fix that, it'll just run without doing anything.


 usable for someone who has no knowledge of programming.  In 
particular, I need some kind of user interface that prompts

the user to input a string (ideally just by putting in numbers in the form 
011123334 for example) and a parameter,
and then displays the output sequence.  This is essentially what the program 
already does but the idea is to make it usable
for even the most technologically disinclined.  Ideally it would do this 
without needing to run Python at all.


Then why are you asking on the Python forum?  Or perhaps you mean 
without him knowing he's running Python?  In that case, use a shebang 
line at the beginning, which will tell Linux to automatically invoke the 
specified program (or programming language in this case).



 If anyone is able to make this happen in Python I would be eternally grateful.



If we assume you're running Python 3.3 on Linux, and the user is willing 
to us the terminal, then how about parsing the string from the command 
line he types?  You can access it as011123334 a string from sys.argv, 
and convert it to separate numbers.  Of course as it stands now, you 
cannot tell whether the user wanted

  0,1,1,1,2,3,3,3,4
or
  0, 111, 23, 3, 3, 4

or something else.



--
DaveA

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

Re: RE Module Performance

[Chris Angelico]

On Fri, Jul 26, 2013 at 5:07 AM,   wrote:
> Let start with a simple string \textemdash or \texttendash
>
 sys.getsizeof('–')
> 40
 sys.getsizeof('a')
> 26

Most of the cost is in those two apostrophes, look:

>>> sys.getsizeof('a')
26
>>> sys.getsizeof(a)
8

Okay, that's slightly unfair (bonus points: figure out what I did to
make this work; there are at least two right answers) but still, look
at what an empty string costs:

>>> sys.getsizeof('')
25

Or look at the difference between one of these characters and two:

>>> sys.getsizeof('aa')-sys.getsizeof('a')
1
>>> sys.getsizeof('––')-sys.getsizeof('–')
2

That's what the characters really cost. The overhead is fixed. It is,
in fact, almost completely insignificant. The storage requirement for
a non-ASCII, BMP-only string converges to two bytes per character.

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

Re: [ANN] bbfreeze 1.1.2

[Ralf Schmitt]

Fábio Santos  writes:

> Seems like it has awesome features, but py3k is really important to me. Is
> this on your roadmap?

Sorry, I don't have a need for python 3 and also don't have a roadmap.

-- 
Cheers
Ralf

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

PyDev 2.8.0 Released

[Fabio Zadrozny]

Hi All,

PyDev 2.8.0 has been released

Details on PyDev: http://pydev.org
Details on its development: http://pydev.blogspot.com

Release Highlights:
---

* Type Inference now works with docstrings (Sphinx or Epydoc). See:
http://pydev.org/manual_adv_type_hints.html

* Fixed debugger to work on Google App Engine

* Patch by Edward Catmur

* Interactive console supports running with the Qt and Gtk event loops

* Patches by Andrew Ferrazzutti

* Multiple main modules/packages may be selected in the unittest run
configuration

* Properly handling unittest errors caused by setUpClass/setUpModule
exceptions

* It's possible to select the Working Set configuration in the New
PyDev Project wizard

* Patches by Christoph Zwerschke

* It's possible to specify PyLint settings per project by passing
--rcfile=.pylintrc (it's now run relative to the project directory)

* PyLint now accepts an executable so that it does not have to rely on
the configured interpreter.

* Fixed OutOfMemoryError when large file was found in the workspace.

* Editor startup is now faster due to improvements in Jython scripts.

* Improved the way that the interpreter location is shown on the pydev
package explorer.

* PyDev Package Explorer icon no longer missing when top level elements is
set to Working Sets

* Other minor bugfixes

Note: PyDev is now signed with a new (self-signed) certificate (see
http://pydev.org/manual_101_install.html for the new certificate) .



What is PyDev?
---

PyDev is a plugin that enables users to use Eclipse for Python, Jython and
IronPython development -- making Eclipse a first class Python IDE -- It
comes with many goodies such as code completion, syntax highlighting,
syntax analysis, refactor, debug and many others.


Cheers,

-- 
Fabio Zadrozny
--
Software Developer

PyDev - Python Development Environment for Eclipse
http://pydev.org
http://pydev.blogspot.com
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: RE Module Performance

[Prasad, Ramit]

Chris Angelico wrote:
> On Fri, Jul 26, 2013 at 5:07 AM,   wrote:
> > Let start with a simple string \textemdash or \texttendash
> >
>  sys.getsizeof('-')
> > 40
>  sys.getsizeof('a')
> > 26
> 
> Most of the cost is in those two apostrophes, look:
> 
> >>> sys.getsizeof('a')
> 26
> >>> sys.getsizeof(a)
> 8
> 
> Okay, that's slightly unfair (bonus points: figure out what I did to
> make this work; there are at least two right answers) but still, look
> at what an empty string costs:

I like bonus points. :)
>>> a = None 
>>> sys.getsizeof(a)
8

Not sure what the other right answer is...booleans take 12 bytes (on 2.6)

> 
> >>> sys.getsizeof('')
> 25
> 
> Or look at the difference between one of these characters and two:
> 
> >>> sys.getsizeof('aa')-sys.getsizeof('a')
> 1
> >>> sys.getsizeof('--')-sys.getsizeof('-')
> 2
> 
> That's what the characters really cost. The overhead is fixed. It is,
> in fact, almost completely insignificant. The storage requirement for
> a non-ASCII, BMP-only string converges to two bytes per character.
> 
> ChrisA
> --
> http://mail.python.org/mailman/listinfo/python-list


Ramit



This email is confidential and subject to important disclaimers and conditions 
including on offers for the purchase or sale of securities, accuracy and 
completeness of information, viruses, confidentiality, legal privilege, and 
legal entity disclaimers, available at 
http://www.jpmorgan.com/pages/disclosures/email.  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: RE Module Performance

[Ian Kelly]

On Wed, Jul 24, 2013 at 9:34 AM, Chris Angelico  wrote:
> On Thu, Jul 25, 2013 at 12:17 AM, David Hutto  wrote:
>> I've screwed up plenty of times in python, but can write code like a pro
>> when I'm feeling better(on SSI and medicaid). An editor can be built simply,
>> but it's preference that makes the difference. Some might have used tkinter,
>> gtk. wxpython or other methods for the task.
>>
>> I think the main issue in responding is your library preference, or widget
>> set preference. These can make you right with some in your response, or
>> wrong with others that have a preferable gui library that coincides with
>> one's personal cognitive structure that makes t
>
> jmf's point is more about writing the editor widget (Scintilla, as
> opposed to SciTE), which most people will never bother to do. I've
> written several text editors, always by embedding someone else's
> widget, and therefore not concerning myself with its internal string
> representation. Frankly, Python's strings are a *terrible* internal
> representation for an editor widget - not because of PEP 393, but
> simply because they are immutable, and every keypress would result in
> a rebuilding of the string. On the flip side, I could quite plausibly
> imagine using a list of strings; whenever text gets inserted, the
> string gets split at that point, and a new string created for the
> insert (which also means that an Undo operation simply removes one
> entire string). In this usage, the FSR is beneficial, as it's possible
> to have different strings at different widths.
>
> But mainly, I'm just wondering how many people here have any basis
> from which to argue the point he's trying to make. I doubt most of us
> have (a) implemented an editor widget, or (b) tested multiple
> different internal representations to learn the true pros and cons of
> each. And even if any of us had, that still wouldn't have any bearing
> on PEP 393, which is about applications, not editor widgets. As stated
> above, Python strings before AND after PEP 393 are poor choices for an
> editor, ergo arguing from that standpoint is pretty useless. Not that
> that bothers jmf...

I think you've just motivated me to finally get around to writing the
custom output widget for my MUD client.  Of course that will be
simpler than a standard rich text editor widget, since it will never
receive input from the user and modifications will (typically) always
come in the form of append operations.  I intend to write it in pure
Python (well, wxPython), however.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: RE Module Performance

[Ian Kelly]

On Thu, Jul 25, 2013 at 12:18 PM, Steven D'Aprano
 wrote:
> On Fri, 26 Jul 2013 01:36:07 +1000, Chris Angelico wrote:
>
>> On Fri, Jul 26, 2013 at 1:26 AM, Steven D'Aprano
>>  wrote:
>>> On Thu, 25 Jul 2013 14:36:25 +0100, Jeremy Sanders wrote:
 "To conserve memory, Emacs does not hold fixed-length 22-bit numbers
 that are codepoints of text characters within buffers and strings.
 Rather, Emacs uses a variable-length internal representation of
 characters, that stores each character as a sequence of 1 to 5 8-bit
 bytes, depending on the magnitude of its codepoint[1]. For example,
 any ASCII character takes up only 1 byte, a Latin-1 character takes up
 2 bytes, etc. We call this representation of text multibyte.
>>>
>>> Well, you've just proven what Vim users have always suspected: Emacs
>>> doesn't really exist.
>>
>> ... lolwut?
>
>
> JMF has explained that it is impossible, impossible I say!, to write an
> editor using a flexible string representation. Since Emacs uses such a
> flexible string representation, Emacs is impossible, and therefore Emacs
> doesn't exist.
>
> QED.

Except that the described representation used by Emacs is a variant of
UTF-8, not an FSR.  It doesn't have three different possible encodings
for the letter 'a' depending on what other characters happen to be in
the string.

As I understand it, jfm would be perfectly happy if Python used UTF-8
(or presumably the Emacs variant) as its internal string
representation.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Creating a Simple User Interface for a Function

[CTSB01]

On Thursday, July 25, 2013 3:19:27 PM UTC-4, Dave Angel wrote:
> On 07/25/2013 12:03 PM, CTSB01 wrote:
> 
> > I have the following code that runs perfectly:
> 
> 
> >   def psi_j(x, j):
> 
> >rtn = []
> 
> >for n2 in range(0, len(x) * j - 2):
> 
> >  n = n2 / j
> 
> >  r = n2 - n * j
> 
> >  rtn.append(j * x[n] + r * (x[n + 1] - x[n]))
> 
> >  print 'n2 =', n2, ': n =', n, ' r =' , r, ' rtn =', rtn
> 
> >return rtn
> 
> No it doesn't run perfectly.  It'll get a syntax error on the print 
> 
> function call.  That's assuming you're still using Python 3.3.  You 
> 
> really need to start by specifying your environment, without making us 
> 
> look back through previous threads from you.
> 
> > This code takes a string x = [0,1,1,1,2] for example
> 
> That's not a string.  A string would be like
> 
> xx = psi_j("0abcd1234")
> 
> Perhaps you mean list?  And is it a list of integers, or of arbitrary 
> 
> numbers?  Are there any constraints on the sizes or signs of those numbers?
> 
> > (it must always begin with 0) and a parameter j, say 2, and outputs a 
> > string (x = [0, 1, 2, 2, 2, 2, 2, 3] in this example).
> 
> > It does this in two steps: First it decomposes some number m into a 
> > multiple of j and a remainder.
> 
> Only if you replace the / with //.  Or just use the function divmod():
> 
>n, r = divmod(n2, m)
> 
> >  Then it runs this decomposition through a function on the rtn.append line.
> 
> > Notice that this has cj - 1 terms where c is the number of terms in the 
> > input string and j is the parameter.  Normally, we would like it to be able 
> > to calculate cj terms.
> 
> > This is an issue with the function that I am more than happy to put aside 
> > for the moment.
> 
> > My key interest is to be able to make this program
> 
> So far you have a function, not a program.  If you put it in a text file 
> 
> and run it from python, it'll do nothing but display a syntax error 
> 
> message.  And when you fix that, it'll just run without doing anything.
> 
>   usable for someone who has no knowledge of programming.  In 
> 
> particular, I need some kind of user interface that prompts
> 
> > the user to input a string (ideally just by putting in numbers in the form 
> > 011123334 for example) and a parameter,
> 
> > and then displays the output sequence.  This is essentially what the 
> > program already does but the idea is to make it usable
> 
> > for even the most technologically disinclined.  Ideally it would do this 
> > without needing to run Python at all.
> 
> Then why are you asking on the Python forum?  Or perhaps you mean 
> 
> without him knowing he's running Python?  In that case, use a shebang 
> 
> line at the beginning, which will tell Linux to automatically invoke the 
> 
> specified program (or programming language in this case).
> 
> >  If anyone is able to make this happen in Python I would be eternally 
> > grateful.
> 
> If we assume you're running Python 3.3 on Linux, and the user is willing 
> 
> to us the terminal, then how about parsing the string from the command 
> 
> line he types?  You can access it as011123334 a string from sys.argv, 
> 
> and convert it to separate numbers.  Of course as it stands now, you 
> 
> cannot tell whether the user wanted
> 
>0,1,1,1,2,3,3,3,4
> 
> or
> 
>0, 111, 23, 3, 3, 4
>
> or something else.
> 
> DaveA

Sorry Dave, to answer each part of your response:

1) I decided to use Python 2.7, and I will be sure to specify this in all 
future threads.
2) It is a list of positive integers.  In fact, it is always going to be a list 
of positive increasing integers.
3) You're right.  What I meant was that if after running that bit of code I 
enter
>>> x = [0,1,2,3,4,5]
>>> psi_j(x,2) 
I will get output that matches my requirements.
4) Yes, sorry that's what I meant (if I understood correctly).  I was told 
elsewhere that I might want to try using tkinter.  Essentially I'm trying to 
create a user interface that allows the user to just type in a string 01112345 
for example, and choose a parameter (say j=2) and then click a button to run 
the function.  I'd like to be able to run send a .exe file that the user can 
just open up and use with no further setup.  

So on top of the user interface I would also it looks like need to determine 
how to make Python change a string 01112345 into a list so that it does that 
automatically when the user clicks 'run'.  

Would a shebang still be the right way to go?  

Thanks again Dave, apologies for the ambiguity.
-- 
http://mail.python.org/mailman/listinfo/python-list

how to package embedded python?

[David M. Cotter]

what must i include in my app package if i'm embedding python?

i tried including *everything* in the "DLLs" directory, but my app still 
crashes as soon as i attempt to initialize python.

this is on a system that does not have python installed, as most of my users 
won't have it.  is it actually a requirement that they first install python?  
(cuz it does work then)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python3, GUIs, game APIs, PyGLet, 2to3...?

[John Ladasky]

On Thursday, July 25, 2013 1:35:43 AM UTC-7, Kushal Kumaran wrote:

> Does your python command mean python2 or python3?  The setup.py at
> https://code.google.com/p/pyglet/source/browse/setup.py seems to run
> 2to3 automatically, but that will only happen if you actually use
> python3 to run setup.py.

Thank you for that sharp observation, Kushal!  (And I hope that more packages 
besides pyglet are configured this way -- to automatically run 2to3, when you 
install on Python 3.)

How strange that I remember typing "sudo python setup.py install".  Because on 
my Ubuntu 13.04 system, that would invoke Python 2.7, which is an essential 
part of the OS.  Nevertheless, I was able to import pyglet after invoking 
"python3" from the shell.  I didn't think that installed modules could be 
shared between multiple Python versions.

I'll try again from scratch, and see whether that clears up my problems.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyGLet on Python 3

[John Ladasky]

Hi Devyn.  After I didn't get a response concerning PyGLet inside this thread, 
I started another thread.  It's here:

https://groups.google.com/forum/#!topic/comp.lang.python/ARtI0GC9RHc
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Creating a Simple User Interface for a Function

[Terry Reedy]

On 7/25/2013 4:58 PM, CTSB01 wrote:


1) I decided to use Python 2.7, and I will be sure to specify this in
all future threads.


Given that you are not using any libraries, let alone one that does not
run on Python 3, I strongly recommend using the latest version (3.3).


2) It is a list of positive integers.  In fact, it is always going to
be a list of positive increasing integers.


Your example below starts with 0, which is not positive.
Perhaps you mean that all integers after a single leading 0 have to be 
positive and increasing.


If you run digits together, then the max int is 9. Do you intend this?


4) Yes, sorry that's what I meant (if I understood correctly).  I was
told elsewhere that I might want to try using tkinter.


If users start the program at a command line, the core of an input 
function would be

  input = (raw)input('Enter digits: ')  # Include "raw" on 2.x
You would need a more elaborate prompt printed first, and input checking 
with the request repeated if the input does not pass the check.


It would be pretty simple to do the equivalent with a tkinter dialog box.


I'd like to be
able to run send a .exe file that the user can just open up and use
with no further setup.


There are programs that will package your code with an interpreter. But 
do give people the option to get just the program without installing a 
duplicate interpreter.



So on top of the user interface I would also it looks like need to
determine how to make Python change a string 01112345 into a list so
that it does that automatically when the user clicks 'run'.


>>> list('01112345')
['0', '1', '1', '1', '2', '3', '4', '5']
>>> '0,1,1,1,2,3,4,5'.split(',')
['0', '1', '1', '1', '2', '3', '4', '5']


Would a shebang still be the right way to go?


On Linux, definitely, whether you have user enter on the command line or
in response to a prompt. On windows, it only helps with 3.3+.

--
Terry Jan Reedy

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

Re: Creating a Simple User Interface for a Function

[Dave Angel]

On 07/25/2013 04:58 PM, CTSB01 wrote:

   


Sorry Dave, to answer each part of your response:

1) I decided to use Python 2.7, and I will be sure to specify this in all 
future threads.
2) It is a list of positive integers.  In fact, it is always going to be a list 
of positive increasing integers.
3) You're right.  What I meant was that if after running that bit of code I 
enter

x = [0,1,2,3,4,5]
psi_j(x,2)

I will get output that matches my requirements.
4) Yes, sorry that's what I meant (if I understood correctly).  I was told 
elsewhere that I might want to try using tkinter.  Essentially I'm trying to 
create a user interface that allows the user to just type in a string 01112345 
for example, and choose a parameter (say j=2) and then click a button to run 
the function.  I'd like to be able to run send a .exe file


But Linux doesn't understand exe files.

Once again, you need to tell us your environment.  I'm now supposing you 
mean your user will be using Windows.  I have no experience with making 
a single runnable .exe file for Windows.  But many others here do, and 
can presumably help you.




that the user can just open up and use with no further setup.

So on top of the user interface I would also it looks like need to determine 
how to make Python change a string 01112345 into a list so that it does that 
automatically when the user clicks 'run'.


Since you give no upper limits to the numbers the user might be 
specifying (other than saying their strictly positively monatonic), the 
string "01112345" could be interpreted only as:



0, 1, 11, 23, 45
0, 11, 12, 345
0, 11, 12345
0, 111, 2345

(If the individual numbers were limited to the range 0-9, then we'd come 
up with the sequence 0,1,1,1,2,3,4,5, but that's not increasing, so it 
wouldn't be legal.)


Is there a reason you don't want the user to have to separate the 
numbers, either with spaces or commas?  If they typed  "0 1 11 23 45" 
you could trivially parse that with something like:

[int(x) for x in data.split()]




Would a shebang still be the right way to go?


A shebang is a Linux/Unix concept.  Although with Python 3.3 there's a 
similar Windows concept that lets a user switch between Python versions 
using the shebang, it's not really the same thing, and we shouldn't 
discuss it till we know whether you're talking Windows or Linux.




Thanks again Dave, apologies for the ambiguity.




--
DaveA

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

Re: Creating a Simple User Interface for a Function

[Terry Reedy]

Some additional comments.

On 7/25/2013 7:00 PM, Terry Reedy wrote:

On 7/25/2013 4:58 PM, CTSB01 wrote:


1) I decided to use Python 2.7, and I will be sure to specify this in
all future threads.


Given that you are not using any libraries, let alone one that does not
run on Python 3, I strongly recommend using the latest version (3.3).


It would be pretty easy to make your simple code run on both 3.x and 
2.6/7. Start your file (after any docstring or initial comment) with

from __future__ import division, print_function

Use "except XyxError as e:" instead of "except XyzError, e:".


If users start the program at a command line, the core of an input
function would be
   numbers = input('Enter digits: ')  # see below
You would need a more elaborate prompt printed first, and input checking
with the request repeated if the input does not pass the check.


# To run on both 2.x and 3.x, put this after the __future__ import:
try:
input = raw_input
except NameError:
pass


I'd like to be
able to run send a .exe file that the user can just open up and use
with no further setup.


There are programs that will package your code with an interpreter.


A Python pre-built binary is overkill for such a small function. The 
reason for doing so, packaging all dependencies together, does not 
apply. Any binary is limited to what machines it will run on.



do give people the option to get just the program without installing a
duplicate interpreter.


A Python file, especially if designed to run on 2.6, will run on most 
any recent installation.


--
Terry Jan Reedy

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

PyGLet, 2to3...?

[John Ladasky]

On Thursday, July 25, 2013 3:26:01 PM UTC-7, John Ladasky wrote:
> I'll try again from scratch, and see whether that clears up my problems.

Nope, that didn't work.

===

john@john:~/Desktop/pyglet-1.2alpha1$ sudo python3 setup.py install

[sudo] password for john: 

running install
running build
running build_py
running install_lib
running install_egg_info
Removing /usr/local/lib/python3.3/dist-packages/pyglet-1.2alpha1.egg-info
Writing /usr/local/lib/python3.3/dist-packages/pyglet-1.2alpha1.egg-info

john@john:~/Desktop/pyglet-1.2alpha1$ python3

Python 3.3.1 (default, Apr 17 2013, 22:30:32) 
[GCC 4.7.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pyglet
Traceback (most recent call last):
  File "", line 1, in 
  File "./pyglet/__init__.py", line 276
print '[%d] %s%s %s' % (thread, indent, name, location)
   ^
SyntaxError: invalid syntax

===

The source code link that Kushal posted is dated December 19, 2012.  Since that 
was several months ago, I double-checked the source code of setup.py in the 
1.2alpha1 package that I downloaded.  It would appear to perform the same check 
of sys.version_info that was shown on the Google Code page.

To see how that check actually runs, I saved a copy of setup.py as setup2.py, 
adding diagnostic calls to print() as shown in the code block below:

===

if sys.version_info >= (3,):
# Automatically run 2to3 when using Python 3
print("Python version is 3.0 or later.") # I added this
if _have_setuptools:
print("Have setuptools.") # I added this
setup_info["use_2to3"] = True
else:
print("Do not have setuptools.") # I added this
from distutils.command.build_py import build_py_2to3
setup_info["cmdclass"] = {"build_py" : build_py_2to3}

===

Here's the output:

===

john@john:~/Desktop/pyglet-1.2alpha1$ sudo python3 setup2.py install

Python version is 3.0 or later.
Do not have setuptools.
running install
running build
running build_py
running install_lib
running install_egg_info
Removing /usr/local/lib/python3.3/dist-packages/pyglet-1.2alpha1.egg-info
Writing /usr/local/lib/python3.3/dist-packages/pyglet-1.2alpha1.egg-info

===

So, I don't know much yet about this _have_setuptools flag.  I don't know 
whether it has to be True, instead of False, in order for 2to3 to work 
properly.  I get the impression from the code that 2to3 should run regardless 
of the _have_setuptools flag, it is just that the task is accomplished in two 
different ways?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: virtualenv problem

[alex23]

On 25/07/2013 11:48 PM, D. Xenakis wrote:

I think there is something wrong with the installation because when i run through idle 
the virtual-env scripts located in "C:\Python33\Scripts" then i get the 
following..


virtualenv is intended to be a command line tool, so running it through 
idle is your first problem :)



You must provide a DEST_DIR
Usage: virtualenv-3.3-script.py [OPTIONS] DEST_DIR


The error you're receiving seems pretty explicit.

Generally, you would go to, say, a projects folder and type at the 
command line:


C:\Projects> virtualenv my-new-project
C:\Projects> cd my-new-project
C:\Projects\my-new-project> Scripts\activate.bat

This will create & enable your virtualenv sandbox.

For more info see:

http://www.virtualenv.org/en/latest/#usage
--
http://mail.python.org/mailman/listinfo/python-list

Hello Everyone! A simple questions!

[Thanatos xiao]

>>> values = [0, 1, 2]>>> values[1] = values>>> values[0, [...], 2]

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

Re: Hello Everyone! A simple questions!

[alex23]

On 26/07/2013 12:15 PM, Thanatos xiao wrote:

 values  =  [0,  1,  2]
 values[1]  =  values
 values

[0,  [...],  2]

why??


First, it helps if you tell us what you were expecting instead.

In your example, you have a list where you have replaced the 2nd element 
with the list itself. The [...] indicates that it is self-referential; 
there is no other way for it to display itself, because the contained 
reference also refers to itself.


>>> values[1]
[0, [...], 2]
>>> values[1][1]
[0, [...], 2]
>>> values[1][1][1][1][1][1][1][1][1]
[0, [...], 2]
>>> values[1][1][1][1][1][1][1][1][1] is values
True
--
http://mail.python.org/mailman/listinfo/python-list

Re: RE Module Performance

[Steven D'Aprano]

On Thu, 25 Jul 2013 15:45:38 -0500, Ian Kelly wrote:

> On Thu, Jul 25, 2013 at 12:18 PM, Steven D'Aprano
>  wrote:
>> On Fri, 26 Jul 2013 01:36:07 +1000, Chris Angelico wrote:
>>
>>> On Fri, Jul 26, 2013 at 1:26 AM, Steven D'Aprano
>>>  wrote:
 On Thu, 25 Jul 2013 14:36:25 +0100, Jeremy Sanders wrote:
> "To conserve memory, Emacs does not hold fixed-length 22-bit numbers
> that are codepoints of text characters within buffers and strings.
> Rather, Emacs uses a variable-length internal representation of
> characters, that stores each character as a sequence of 1 to 5 8-bit
> bytes, depending on the magnitude of its codepoint[1]. For example,
> any ASCII character takes up only 1 byte, a Latin-1 character takes
> up 2 bytes, etc. We call this representation of text multibyte.

 Well, you've just proven what Vim users have always suspected: Emacs
 doesn't really exist.
>>>
>>> ... lolwut?
>>
>>
>> JMF has explained that it is impossible, impossible I say!, to write an
>> editor using a flexible string representation. Since Emacs uses such a
>> flexible string representation, Emacs is impossible, and therefore
>> Emacs doesn't exist.
>>
>> QED.
> 
> Except that the described representation used by Emacs is a variant of
> UTF-8, not an FSR.  It doesn't have three different possible encodings
> for the letter 'a' depending on what other characters happen to be in
> the string.
> 
> As I understand it, jfm would be perfectly happy if Python used UTF-8
> (or presumably the Emacs variant) as its internal string representation.


UTF-8 uses a flexible representation on a character-by-character basis. 
When parsing UTF-8, one needs to look at EVERY character to decide how 
many bytes you need to read. In Python 3, the flexible representation is 
on a string-by-string basis: once Python has looked at the string header, 
it can tell whether the *entire* string takes 1, 2 or 4 bytes per 
character, and the string is then fixed-width. You can't do that with 
UTF-8.

To put it in terms of pseudo-code:

# Python 3.3
def parse_string(astring):
# Decision gets made once per string.
if astring uses 1 byte:
count = 1
elif astring uses 2 bytes:
count = 2
else: 
count = 4
while not done:
char = convert(next(count bytes))


# UTF-8
def parse_string(astring):
while not done:
b = next(1 byte)
# Decision gets made for every single char
if uses 1 byte:
char = convert(b)
elif uses 2 bytes:
char = convert(b, next(1 byte))
elif uses 3 bytes:
char = convert(b, next(2 bytes))
else:
char = convert(b, next(3 bytes))


So UTF-8 requires much more runtime overhead than Python 3.3, and Emac's 
variation can in fact require more bytes per character than either. 
(UTF-8 and Python 3.3 can require up to four bytes, Emacs up to five.) 
I'm not surprised that JMF would prefer UTF-8 -- he is completely out of 
his depth, and is a fine example of the Dunning-Kruger effect in action. 
He is so sure he is right based on so little evidence.

One advantage of UTF-8 is that for some BMP characters, you can get away 
with only three bytes instead of four. For transmitting data over the 
wire, or storage on disk, that's potentially up to a 25% reduction in 
space, which is not to be sneezed at. (Although in practice it's usually 
much less than that, since the most common characters are encoded to 1 or 
2 bytes, not 4). But that comes at the cost of much more runtime 
overhead, which in my opinion makes UTF-8 a second-class string 
representation compared to fixed-width representations.



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

Re: RE Module Performance

[Michael Torrie]

On 07/25/2013 01:07 PM, wxjmfa...@gmail.com wrote:
> Let start with a simple string \textemdash or \texttendash
> 
 sys.getsizeof('–')
> 40
 sys.getsizeof('a')
> 26

That's meaningless.  You're comparing the overhead of a string object
itself (a one-time cost anyway), not the overhead of storing the actual
characters.  This is the only meaningful comparison:

 sys.getsizeof('––') - sys.getsizeof('–')

 sys.getsizeof('aa') - sys.getsizeof('a')

Actually I'm not even sure what your point is after all this time of
railing against FSR.  You have said in the past that Python penalizes
users of character sets that require wider byte encodings, but what
would you have us do? use 4-byte characters and penalize everyone
equally?  Use 2-byte characters that incorrectly expose surrogate pairs
for some characters? Use UTF-8 in memory and do O(n) indexing?  Are your
programs (actual programs, not contrived benchmarks) actually slower
because of FSR?  Is FSR incorrect?  If so, according to what part of the
unicode standard?  I'm not trying to troll, or feed the troll.  I'm
actually curious.

I think perhaps you feel that many of us who don't use unicode often
don't understand unicode because some of us don't understand you.  If
so, I'm not sure that's actually true.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: RE Module Performance

[Michael Torrie]

On 07/25/2013 11:18 AM, Steven D'Aprano wrote:
> JMF has explained that it is impossible, impossible I say!, to write an 
> editor using a flexible string representation. Since Emacs uses such a 
> flexible string representation, Emacs is impossible, and therefore Emacs 
> doesn't exist.

Now I'm even more confused.  He once pointed to Go as an example of how
unicode should be done in a language.  yet Go uses UTF-8 I think.

But I don't think UTF-8 is what JMF refers to as "flexible string
representation."  FSR does use 1,2 or 4 bytes per character, but each
character in the string uses the same width.  That's different from
UTF-8 or UTF-16, which is variable width per character.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Hello Everyone! A simple questions!

[Ben Finney]

Thanatos xiao  writes:

> >>> values = [0, 1, 2]>>> values[1] = values>>> values[0, [...], 2]
>
> why??

Because. :-)

Did you have a more specific question? What exactly are you expecting
that code to do, and what is the surprise?

-- 
 \  “I was the kid next door's imaginary friend.” —Emo Philips |
  `\   |
_o__)  |
Ben Finney

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

How would I do this?

[John Doe]

Hey guys,

I;m working on making a chess program and I hit a wall. I have no idea how to 
get the position of the chess pieces. I have the chess board 1-8 and A-H for 
black as well as 1-8 and a-h for white. i just have to figure out how to 
declare those positions for the actual pieces so like the row of pawns for 
black would be B1-B8 as well as be able to replace the other coordinates with 
the piece when they move there like if I moved a black pawn from B1 to C1 B1 
would be empty and then C1 would have it. 

I'm sorry if that's confusing but I can't seem to figure out how to do it... 
Any help is greatly appreciated and thank you in advance!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: RE Module Performance

[Ian Kelly]

On Thu, Jul 25, 2013 at 8:48 PM, Steven D'Aprano
 wrote:
> UTF-8 uses a flexible representation on a character-by-character basis.
> When parsing UTF-8, one needs to look at EVERY character to decide how
> many bytes you need to read. In Python 3, the flexible representation is
> on a string-by-string basis: once Python has looked at the string header,
> it can tell whether the *entire* string takes 1, 2 or 4 bytes per
> character, and the string is then fixed-width. You can't do that with
> UTF-8.

UTF-8 does not use a flexible representation.  A codec that is
encoding a string in UTF-8 and examining a particular character does
not have any choice of how to encode that character; there is exactly
one sequence of bits that is the UTF-8 encoding for the character.
Further, for any given sequence of code points there is exactly one
sequence of bytes that is the UTF-8 encoding of those code points.  In
contrast, with the FSR there are as many as three different sequences
of bytes that encode a sequence of code points, with one of them (the
shortest) being canonical.  That's what makes it flexible.

Anyway, my point was just that Emacs is not a counter-example to jmf's
claim about implementing text editors, because UTF-8 is not what he
(or anybody else) is referring to when speaking of the FSR or
"something like the FSR".
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How would I do this?

[Ian Kelly]

On Thu, Jul 25, 2013 at 9:16 PM, John Doe  wrote:
> Hey guys,
>
> I;m working on making a chess program and I hit a wall. I have no idea how to 
> get the position of the chess pieces. I have the chess board 1-8 and A-H for 
> black as well as 1-8 and a-h for white. i just have to figure out how to 
> declare those positions for the actual pieces so like the row of pawns for 
> black would be B1-B8 as well as be able to replace the other coordinates with 
> the piece when they move there like if I moved a black pawn from B1 to C1 B1 
> would be empty and then C1 would have it.
>
> I'm sorry if that's confusing but I can't seem to figure out how to do it... 
> Any help is greatly appreciated and thank you in advance!

The usual way to do this would be to represent the board as an 8x8
list of lists, with each item of the inner lists representing one
space on the board and denoting its contents.  For example, you might
have board[1][4] = 'P', indicating that E2 (1, 4 in zero-based
row-column coordinates) holds a white pawn.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How would I do this?

[h4ck3rpr0n3]

Thank you for the quick reply. Unfortunately I'm still a little confused... How 
might I implement that into my current code?

def Make_Board():
Col = "+--+"
Row = "|  |"
Col2 = "--+"
Row2 = "  |"
print(" ", Col + Col2 + Col2 + Col2 + Col2 + Col2 + Col2 + Col2)
print("1", Row + Row2 + Row2 + Row2 + Row2 + Row2 + Row2 + Row2, "1")
print(" ", Col + Col2 + Col2 + Col2 + Col2 + Col2 + Col2 + Col2)
print("2", Row + Row2 + Row2 + Row2 + Row2 + Row2 + Row2 + Row2, "2")
print(" ", Col + Col2 + Col2 + Col2 + Col2 + Col2 + Col2 + Col2)
print("3", Row + Row2 + Row2 + Row2 + Row2 + Row2 + Row2 + Row2, "3")
print(" ", Col + Col2 + Col2 + Col2 + Col2 + Col2 + Col2 + Col2)
print("4", Row + Row2 + Row2 + Row2 + Row2 + Row2 + Row2 + Row2, "4")
print(" ", Col + Col2 + Col2 + Col2 + Col2 + Col2 + Col2 + Col2)
print("5", Row + Row2 + Row2 + Row2 + Row2 + Row2 + Row2 + Row2, "5")
print(" ", Col + Col2 + Col2 + Col2 + Col2 + Col2 + Col2 + Col2)
print("6", Row + Row2 + Row2 + Row2 + Row2 + Row2 + Row2 + Row2, "6")
print(" ", Col + Col2 + Col2 + Col2 + Col2 + Col2 + Col2 + Col2)
print("7", Row + Row2 + Row2 + Row2 + Row2 + Row2 + Row2 + Row2, "7")
print(" ", Col + Col2 + Col2 + Col2 + Col2 + Col2 + Col2 + Col2)
print("8", Row + Row2 + Row2 + Row2 + Row2 + Row2 + Row2 + Row2, "8")
print(" ", Col + Col2 + Col2 + Col2 + Col2 + Col2 + Col2 + Col2)

def Col_Label():
Col_Label_Black = "A  B  C  D  E  F  G  H"
print(Col_Label_Black)

def Col_Label2():
Col_Label_White = "A  B  C  D  E  F  G  H"
Col_Label_White = Col_Label_White.lower()
print(Col_Label_White)

def Board():
Col_Label()
Make_Board()
Col_Label2()

Board()



Thanks again for your help!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How would I do this?

[Ian Kelly]

On Thu, Jul 25, 2013 at 9:40 PM,   wrote:
> Thank you for the quick reply. Unfortunately I'm still a little confused... 
> How might I implement that into my current code?

Where you print spaces indicating an empty space, you need to look up
the current square in the board data structure to see what is
contained there (whether it's an empty space or not) and print it
accordingly.

I strongly recommend that you work out how to print the board using
nested for loops instead of all those individual print statements.
The result will be more compact, easier to work with, and less
error-prone.  The basic skeleton should look something like this:

for row in range(8):
for column in range(8):
print(board[row][column])

Which you'll need to embellish with the row and column dividers and labels.
-- 
http://mail.python.org/mailman/listinfo/python-list

Help

[tyler]

I'm a bit new to python and I'm trying to create a simple program which adds 
words and definitions to a list, and then calls them forward when asked to.

---
choice = 0

words = []

entry = 0

definition = 0

escape = 0

finish = 0

memory = 0

dictionary = []

search = 0

def ask_ok(prompt, retries=2, complaint='Yes or no, please!'):
while True:
ok = input(prompt)
if ok in ('y', 'ye', 'yes'):
return True
if ok in ('n', 'no', 'nop', 'nope'):
return False
retries = retries - 1
if retries < 0:
raise IOError('refusenik user')
print(complaint)


print("Welcome to Digital Dictionary V1.0!\n\n")

while escape < 1:

choice = input("Type 'Entry' to add a word to the Dictionary, 'Search' to 
find a word, and 'Exit' to quit. ")

if choice == '`':
break

if choice == 'Entry' or 'entry':
while finish < 1:
entry = input("Please type the word you wish to add: ")
words.append(entry)
definition = input("What does the word mean?\n ")
dictionary.append(definition)
print(entry, '\n', definition)
ask_ok("Is this entry complete? ")
if True:
finish = 1
entry = 0
definition = 0

elif choice == 'Search' or 'search':
search = input("Please type the word you wish to find: ")
print(search in words)


elif choice == 'Exit' or 'exit':
ask_ok("Are you sure you want to exit? ")
if True:
escape = 1

else:
print("Please choose an option from the list.")
---
However, if I run the program using anything but 'entry', the program still 
runs the 'entry' subroutine. After the 'entry' subroutine is run once, no 
options work. Ex:
---
>>> 
Welcome to Digital Dictionary V1.0!

Type 'Entry' to add a word to the Dictionary, 'Search' to find a word, and 
'Exit' to quit. entry
Please type the word you wish to add: computer
What does the word mean?
 a device for computing
computer 
 a device for computing
Is this entry complete? yes
Type 'Entry' to add a word to the Dictionary, 'Search' to find a word, and 
'Exit' to quit. search
Type 'Entry' to add a word to the Dictionary, 'Search' to find a word, and 
'Exit' to quit. exit
Type 'Entry' to add a word to the Dictionary, 'Search' to find a word, and 
'Exit' to quit. `
>>>
---
The only option which seems to work is the '`' subroutine, which I added to 
stop the program after running for a while. I believe it works because it was 
added before the 'entry' subroutine.

If anyone can help me figure out why it won't run properly, I'd be really 
grateful.
P.S: I haven't finished the 'search' subroutine, but I just want to get this 
small problem solved soon so I can
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Help

[alex23]

On 26/07/2013 3:06 PM, ty...@familyrobbins.com wrote:

I'm a bit new to python and I'm trying to create a simple program which adds 
words and definitions to a list, and then calls them forward when asked to.

---
choice = 0

words = []

entry = 0

definition = 0

escape = 0

finish = 0

memory = 0

dictionary = []

search = 0

def ask_ok(prompt, retries=2, complaint='Yes or no, please!'):
 while True:
 ok = input(prompt)
 if ok in ('y', 'ye', 'yes'):
 return True
 if ok in ('n', 'no', 'nop', 'nope'):
 return False
 retries = retries - 1
 if retries < 0:
 raise IOError('refusenik user')
 print(complaint)


print("Welcome to Digital Dictionary V1.0!\n\n")

while escape < 1:

 choice = input("Type 'Entry' to add a word to the Dictionary, 'Search' to find 
a word, and 'Exit' to quit. ")

 if choice == '`':
 break

 if choice == 'Entry' or 'entry':
 while finish < 1:
 entry = input("Please type the word you wish to add: ")
 words.append(entry)
 definition = input("What does the word mean?\n ")
 dictionary.append(definition)
 print(entry, '\n', definition)
 ask_ok("Is this entry complete? ")
 if True:
 finish = 1
 entry = 0
 definition = 0

 elif choice == 'Search' or 'search':
 search = input("Please type the word you wish to find: ")
 print(search in words)


 elif choice == 'Exit' or 'exit':
 ask_ok("Are you sure you want to exit? ")
 if True:
 escape = 1

 else:
 print("Please choose an option from the list.")
---
However, if I run the program using anything but 'entry', the program still 
runs the 'entry' subroutine. After the 'entry' subroutine is run once, no 
options work. Ex:
---



Welcome to Digital Dictionary V1.0!

Type 'Entry' to add a word to the Dictionary, 'Search' to find a word, and 
'Exit' to quit. entry
Please type the word you wish to add: computer
What does the word mean?
  a device for computing
computer
  a device for computing
Is this entry complete? yes
Type 'Entry' to add a word to the Dictionary, 'Search' to find a word, and 
'Exit' to quit. search
Type 'Entry' to add a word to the Dictionary, 'Search' to find a word, and 
'Exit' to quit. exit
Type 'Entry' to add a word to the Dictionary, 'Search' to find a word, and 
'Exit' to quit. `



---
The only option which seems to work is the '`' subroutine, which I added to 
stop the program after running for a while. I believe it works because it was 
added before the 'entry' subroutine.

If anyone can help me figure out why it won't run properly, I'd be really 
grateful.


This doesn't do what you think it does:

> if choice == 'Entry' or 'entry':

Python interprets this as:

if (choice == 'Entry') or 'entry':

And as non-empty strings are considered True, it will always succeed and 
run the associated code block. The same goes for the subsequent 
conditions, but because you break out of the loop in the 'entry' 
section, it never reaches them.


You do have it right in your `ask_ok` function, so just rewrite the 
conditions in a similar way:


if choice in ('Entry', 'entry'):

Or even better, always make the input lower case and then you only have 
one case to test for:


choice = input("Type 'Entry' to etc ... ")
choice = choice.lower()

...

if choice == 'entry':
...

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

Re: Help

[Peter Otten]

ty...@familyrobbins.com wrote:

> I'm a bit new to python and I'm trying to create a simple program which
> adds words and definitions to a list, and then calls them forward when
> asked to.

> while escape < 1:
> 
> choice = input("Type 'Entry' to add a word to the Dictionary, 'Search'
> to find a word, and 'Exit' to quit. ")
> 
> if choice == '`':
> break
> 
> if choice == 'Entry' or 'entry':

> However, if I run the program using anything but 'entry', the program
> still runs the 'entry' subroutine. After the 'entry' subroutine is run
> once, no options work. Ex:

The expression 

choice == 'Entry' or 'entry'

is evaluated by Python as

(choice == 'Entry') or 'entry'

All strings but "" are True in a boolean context, so this has the same 
effect as

(choice == 'Entry') or True

and is always True. Possible fixes:

if choice == "Entry" or choice == "entry":
if choice in ("Entry", "entry"):
if choice.casefold() == "entry".casefold(): # will accept ENTRY, eNtRy etc.

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

Re: Help

[Chris Angelico]

On Fri, Jul 26, 2013 at 6:06 AM,   wrote:
> I'm a bit new to python and I'm trying to create a simple program which adds 
> words and definitions to a list, and then calls them forward when asked to.

One of the most important tidbits of information is: What version of
Python are you using?

> print("Welcome to Digital Dictionary V1.0!\n\n")

This looks like Python 3 style, though it would be valid Python 2 too.

> choice = input("Type 'Entry' to add a word to the Dictionary, 'Search' to 
> find a word, and 'Exit' to quit. ")

And I sincerely hope that this is Python 3, otherwise it would be
doing some very strange and dangerous things. However, relying on us
to guess isn't particularly safe, and works only for the major branch
of 2.x vs 3.x. The actual version you're using will be helpful.

> while finish < 1:
> if True:
> finish = 1
> entry = 0
> definition = 0

You're doing a lot with sentinel values, and it's getting a bit
confusing. Your problem here seems to be that 'finish' is never reset,
so the second time through, your loop is completely skipped. I
recommend instead that you use 'break' to exit your loops.

In a piece of somewhat amusing irony, you're here trying to implement
a dictionary. Python has an object type of that name ('dict' is short
for dictionary), which will be extremely useful here. I advise you to
explore it - it'll replace your words[] and dictionary[] lists.

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

Re: Help

[Terry Reedy]

On 7/26/2013 1:06 AM, ty...@familyrobbins.com wrote:

I'm a bit new to python and I'm trying to create a simple program
which adds words and definitions to a list, and then calls them
forward when asked to.


Why are you not putting them in a Python dict, which is made for this? 
Unless you have a very specialized purpose, it would be more educational 
about Python programming.


--
Terry Jan Reedy

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

Re: Hello Everyone! A simple questions!

[Thanatos xiao]

Thanks
I just surprised by three dot


2013/7/26 Florian Baumgartner 

> As alex23 already indicated you created a recursive data-structure (by
> inserting a reference to the list into the second place of the list) and
> the interpreter handles this gracefully by showing [...].
>
> In case you really want to insert the lists members into the second place
> you can assign a copy of the list.
>
> values = [0,1,2]
> values[1] = values[:]
>
>
>
>
>
> 2013/7/26 Thanatos xiao 
>
>> >>> values = [0, 1, 2]>>> values[1] = values>>> values[0, [...], 2]
>>
>> why??
>>
>>
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>>
>>
>
-- 
http://mail.python.org/mailman/listinfo/python-list

embedded python and threading

[David M. Cotter]

in my app i initialize python on the main thread, then immediately call 
PyEval_SaveThread() because i do no further python stuff on the main thread.

then, for each script i want to run, i use boost::threads to create a new 
thread, then on that thread i "ensure" the GIL, do my stuff, then release it.

so, to test concurrency, on my first background thread, i do an infinite loop 
that just logs "i'm alive", then calls sleep(0.25)

so that thread continues to run forever (with it's GIL ensured)

according to the doc: "In order to emulate concurrency of execution, the 
interpreter regularly tries to switch threads"

so i figure i can run another thread that does a single print statement:

> ensure gil
> print my thing
> release gil

and this DOES run.  however, after releasing it's gil, i guess the interpeter 
gets back to the first back thread, but then has this error immediately:

9: Traceback (most recent call last):
9:   File "", line 70, in ?
9:   File "", line 55, in main
9: AttributeError: 'builtin_function_or_method' object has no attribute 
'sleep'

suddenly the sleep module has been unloaded?? huh?  i thought the thread state 
had been preserved?
-- 
http://mail.python.org/mailman/listinfo/python-list