Re: Replace weird error message?

[Joel Goldstick]

On Wed, Mar 16, 2016 at 2:53 PM, Ben Finney 
wrote:

> "the.gerenuk--- via Python-list"  writes:
>
> > The following error message, makes it a bit hard to understand what went
> wrong
> >
> > >>> "{:02}".format("1")
> > Traceback (most recent call last):
> >   File "", line 1, in 
> > ValueError: '=' alignment not allowed in string format specifier
>
> Meaning that the ‘str.format’ mini-language parser has decided on the
> alignment specifier “=”. It's chosen that because:
>
> Preceding the width field by a zero ('0') character enables
> sign-aware zero-padding for numeric types. This is equivalent to a
> fill character of '0' with an alignment type of '='.
>
> https://docs.python.org/3/library/string.html#formatspec>
>
> Nothing in the error message indicates why “'=' alignment” is relevant,
> and it does not appear in the code.
>
> > Do you think some better error message should be used?
>
> Yes, I think that error message needs to be improved. Please file a bug
> report in Python's issue tracker https://bugs.python.org/>.
>
> > For example a hint that "0" does work for the given argument.
>
> I suggest: “zero-padding only allowed for numeric types, not 'str'”.
>
> --
>  \ “In economics, hope and faith coexist with great scientific |
>   `\  pretension and also a deep desire for respectability.” —John |
> _o__)Kenneth Galbraith, 1970-06-07 |
> Ben Finney
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>

I stand corrected.  It was awfully misleading.  So much so that I thought
some other code must have been missing.

-- 
Joel Goldstick
http://joelgoldstick.com/ 
http://cc-baseballstats.info/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Bash-like pipes in Python

[Omar Abou Mrad]

On Wed, Mar 16, 2016 at 5:39 PM, Steven D'Aprano 
wrote:

> On Thu, 17 Mar 2016 02:22 am, Omar Abou Mrad wrote:
>
> > Would be nice if this was possible:
> >
>  get_digits = Filter(str.isdigit) | Map(int)
>  'kjkjsdf399834' | get_digits
>
>
> Yes it would. I'll work on that.
>
>
> > Also, how about using '>>' instead of '|' for "Forward chaining"
>
> Any particular reason you prefer >> over | as the operator?


Nothing major, only that it's closer to visual "forward" a la F#'s |>
operator.
I tend to see | as an indication of "OR" (bit or otherwise) rather than pipe
(which I completely understand why you picked it).

On a somewhat related note I had experimented with an overridden '|'
a while ago to lift conditions and compose them (which is what spurred
the get_digits question).

https://gist.github.com/omaraboumrad/8424298
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: WP-A: A New URL Shortener

[Rick Johnson]

On Thursday, March 17, 2016 at 4:15:37 PM UTC-5, Thomas 'PointedEars' Lahn 
wrote:
 
> Get a life, *please*.

Well, you see *Thomas*, the problem is, this *IS* my life! I couldn't remove 
myself from this life anymore than you could apply a Bézier curve to your upper 
auricles -- we just wouldn't be same anymore!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: empty clause of for loops

[Sven R. Kunze]

On 16.03.2016 17:20, Terry Reedy wrote:

On 3/16/2016 11:17 AM, Sven R. Kunze wrote:

On 16.03.2016 16:02, Tim Chase wrote:



Does it annoy me when I have to work in other languages that lack
Python's {for/while}/else functionality?  You bet.


I can imagine that. Could you describe the general use-case? From what I
know, "else" is executed when you don't "break" the loop. When is this
useful?


When one wants to know if the iterable contained an exceptional item 
or not


I don't think that's all since I wouldn't need the "else" clause here. 
The important part here is that there is code attached to the case of 
"item found".


That naturally leads to what when I want to attach code to the case of 
"no item found"?



or when one wants to know if the iterator is exhausted or not.


That's not 100% true, isn't it? The break could happen during iterating 
over the last item of the iterable.


I vaguely remember this being a problem, why I always needed to dismiss 
the "else" idea in my code because of that very corner case.



Best,
Sven
--
https://mail.python.org/mailman/listinfo/python-list

Re: MIT Python Tool - beta testers

[Chris Patti]

Hi Ashton, I'd love to give it a try. I'm on OSX Yosemite.

Thanks!
-Chris

Sent from my iPad

> On Mar 15, 2016, at 7:23 PM, Ashton Braun  wrote:
> 
> Kite is an MIT startup developing a new type of programming tool /
> programming assistant.
> 
> We are looking for python programmers who write code on OS X. If this is
> you and you're interested in offering feedback on a new product, please
> email us: b...@kite.com.
> 
> Thanks!,
> Ashton
> 
> -- 
> Ashton Braun  | kite
> -- 
> https://mail.python.org/mailman/listinfo/python-announce-list
> 
>Support the Python Software Foundation:
>http://www.python.org/psf/donations/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: from a module return a class

[John Gordon]

In  kevind0...@gmail.com 
writes:

> ##  prompt the user for a User name a& pWord
> user_pword = promptUser_PWord()   

> I get the error 
>   File "H:\dev\eclipse\workspace\genXls\src\genXls\promptUser_PWord.py", line 
> 58
> return user_pword
> SyntaxError: 'return' outside function

Show us the complete definition of promptUser_PWord().

-- 
John Gordon   A is for Amy, who fell down the stairs
gor...@panix.com  B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

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

Re: How to waste computer memory?

[Tim Golden]

On 18/03/2016 18:18, sohcahto...@gmail.com wrote:

On Thursday, March 17, 2016 at 7:34:46 AM UTC-7, wxjm...@gmail.com
wrote:

Very simple. Use Python and its (buggy) character encoding model.

How to save memory? It's also very simple. Use a programming
language, which handles Unicode correctly.


*looks at the other messages in this thread*

...

Whatever happened to the idea of not feeding the trolls?  This image
depicts this thread perfectly:

http://i.imgur.com/sVtpZDK.png



Speaking for a moment as the list owner. Posts by this OP are usually 
blatant provocation and I usually filter them out before they hit the 
list. (They'll still appear if you're reading via Usenet). In this case 
I approved a post thinking it was something else.


However... for the most part, the result here has been either humorous 
banter or an informed and civil discussion of the pros and cons of 
various unicode-related issues. Nothing wrong with that.


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

Re: from a module return a class

[Wolfgang Maier]

On 18.03.2016 16:08, John Gordon wrote:

In  kevind0...@gmail.com 
writes:


As requested , full code for promptUser_PWord




So promptUser_PWord is a module?  Well, I'm confused.  You gave us this
bit of code:

 user_pword = promptUser_PWord()

But that can't work if promptUser_PWord is a module; modules aren't
callable.  promptUser_PWord() has to be a function or a class.



Yes, but I guess the OP's program will run into the SyntaxError when 
trying to import the module, i.e., before it ever encounters the 
TypeError: 'module' object is not callable.


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

Re: empty clause of for loops

[alister]

On Wed, 16 Mar 2016 11:47:31 +0100, Peter Otten wrote:

> Sven R. Kunze wrote:
> 
>> Hi,
>> 
>> a colleague of mine (I write this mail because I am on the list) has
>> the following issue:
>> 
>> 
>> for x in my_iterable:
>>  # do
>> empty:
>>  # do something else
>> 
>> 
>> What's the most Pythonic way of doing this?
> 
> What would you expect?
> 
 class Empty(Exception): pass
> ...
 def check_empty(items):
> ... items = iter(items)
> ... try:
> ... yield next(items)
> ... except StopIteration:
> ... raise Empty ... yield from items ...
 try:
> ...for item in check_empty("abc"): print(item)
> ... except Empty: print("oops")
> ...
> a
> b
> c
 try:
> ...for item in check_empty(""): print(item)
> ... except Empty: print("oops")
> ...
> oops
> 
> I'm kidding, of course. Keep it simple and use a flag like you would in
> any other language:
> 
> empty = True:
> for item in items:
> empty = False ...
> if empty:
> ...

or even use the loop variable as the flag

item=None
for item in items:
#do stuff
if ex is None:
#do something else




-- 
Love means never having to say you're sorry.
-- Eric Segal, "Love Story"

That's the most ridiculous thing I've ever heard.
-- Ryan O'Neill, "What's Up Doc?"
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: creating multiple python Django projects in Windows environment

[Reto Brunner]

Hi Ivan,
The idea is basically that you provide a web frontend on a server (internet
or intranet) which provides just a web interface that enables eg the upload
of an excel sheet.

On the server the data gets processed (in this example  makes the "clean"
excel) and then allows the user to download the results.

The only dependency the user has is a web browser then and only the server
needs python,  django and the other stuff you need for the parsing.

On Sat, Mar 19, 2016, 01:07 Ivan Jankovic  wrote:

> Hi Reto.
>
> I understand that i need to run Django on a server.  I have deployed
> projects to AWS (ubuntu) in the past.
>
> My main question is around how to tie it into the windows environment.
>
> Ivan
> On Mar 18, 2016 7:40 PM, Reto Brunner  wrote:
>
> Well you can just put it on a proper server. In the end that's what django
> is for yes?
> In case that isn't an option and you don't want to install python there's
> docker,  but then you would need to install that...
>
> On Fri, Mar 18, 2016, 20:05 jogaserbia  wrote:
>
> Hello,
>
> At work, I have a windows environment.
>
> I have created applications on my linux ubuntu machine at home that I
> would like to use for work purposes.
>
> For example, I have:
>
> - a Django project that takes inputs from users and creates pdfs
> - a Django project that tracks various company related information
> - a python project that parses word documents and returns clean excel
> documents (the documents to be parsed would be on the local machine)
> - a python project that uses scikit learn to make decisions which
> customers should get which marketing campaigns
>
> What I would like to know is how I should create an environment (vagrant,
> virtualbox running linux on an existing Windows machine in my network?) and
> connect it to my windows environment so that staff can assess these
> applications.
>
> I would prefer not to have to install python on everyone's computer who
> might need to use the programs so as not to have to maintain each
> workstation.
>
> Can someone please give me ideas on what I should read about (or pay
> someone to do) that would enable me to create a basis on which multiple
> Python (web and non-web) applications can be access by staff in a windows
> environment.
>
> Thank you, and sorry if the question is a bit convoluted, I am trying to
> get my head around how to create a basis from which to create company wide
> access to applications.
>
> Ivan
> --
> https://mail.python.org/mailman/listinfo/python-list
>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Case Statements

[Marko Rauhamaa]

Antoon Pardon :

> Look at decorators. They don't provide functionality we wouldn't have
> without them. So we don't actually need them. Do you argue that
> introducing them wasn't progress?

I do.


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

Re: creating multiple python Django projects in Windows environment

[Ivan Jankovic]

Hi Reto.

I understand that i need to run Django on a server.  I have deployed projects 
to AWS (ubuntu) in the past.

My main question is around how to tie it into the windows environment.

Ivan

On Mar 18, 2016 7:40 PM, Reto Brunner  wrote:

Well you can just put it on a proper server. In the end that's what django is 
for yes?
In case that isn't an option and you don't want to install python there's 
docker,  but then you would need to install that...

On Fri, Mar 18, 2016, 20:05 jogaserbia 
mailto:ivanjanko...@live.ca>> wrote:
Hello,

At work, I have a windows environment.

I have created applications on my linux ubuntu machine at home that I would 
like to use for work purposes.

For example, I have:

- a Django project that takes inputs from users and creates pdfs
- a Django project that tracks various company related information
- a python project that parses word documents and returns clean excel documents 
(the documents to be parsed would be on the local machine)
- a python project that uses scikit learn to make decisions which customers 
should get which marketing campaigns

What I would like to know is how I should create an environment (vagrant, 
virtualbox running linux on an existing Windows machine in my network?) and 
connect it to my windows environment so that staff can assess these 
applications.

I would prefer not to have to install python on everyone's computer who might 
need to use the programs so as not to have to maintain each workstation.

Can someone please give me ideas on what I should read about (or pay someone to 
do) that would enable me to create a basis on which multiple Python (web and 
non-web) applications can be access by staff in a windows environment.

Thank you, and sorry if the question is a bit convoluted, I am trying to get my 
head around how to create a basis from which to create company wide access to 
applications.

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

Re: sobering observation, python vs. perl

[Marko Rauhamaa]

"Charles T. Smith" :

> On Thu, 17 Mar 2016 15:29:47 +, Charles T. Smith wrote:
>
> And for completeness, and also surprising:
>
> time sed -n -e '/ is ready/{s///;h}' -e '/release_req/{g;p}'  *.out | sort -u
> TestCase_F_00_P
> TestCase_F_00_S
> TestCase_F_01_S
> TestCase_F_02_M
>
> real0m10.998s
> user0m10.885s
> sys 0m0.108s
>
> Twice as long as perl...  I guess there's no excuse for sed anymore...

Try running the sed command again after setting:

export LANG=C


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

submodules

[ast]

Hello

Since in python3 ttk is a submodule of tkinter, I was expecting this
to work:

from tkinter import *

root = Tk()
nb = ttk.Notebook(root)

but it doesnt, ttk is not known.

I have to explicitely import ttk with

from tkinter import ttk

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

Re: How to waste computer memory?

[Steven D'Aprano]

On Sat, 19 Mar 2016 02:26 am, Marko Rauhamaa wrote:

> Michael Torrie :
> 
>> On 03/18/2016 02:26 AM, Jussi Piitulainen wrote:
>>> I think Julia's way of dealing with its strings-as-UTF-8 [2] is more
>>> promising. Indexing is by bytes (1-based in Julia) but the value at a
>>> valid index is the whole UTF-8 character at that point, and an
>>> invalid index raises an exception.
>>
>> This seems to me to be a leaky abstraction.
> 
> It may be that Python's Unicode abstraction is an untenable illusion
> because the underlying reality is 8-bit and there's no way to hide it
> completely.
>
> There's no problem providing pure Unicode strings. Things get iffy when
> Python's OS abstraction pretends sys.stdin is text or filenames are
> strings.

The abstraction only breaks because of historical reasons.

In Linux and Unix systems, the underlying file system actually allows any
arbitrary byte strings (with a small number of restrictions, such as
disallowing ASCII NUL and / (slash) bytes. But modern applications try to
pretend that the file system is actually UTF-8. That would work fine if
people *only* accessed the file system with such tools that used UTF-8. But
they don't.

On Windows, the file system is either UTF-16 or UCS-2, I'm not sure which.
But the NTFS file system itself enforces that all file names are valid
UTF-16 (or the other one). Since all valid UTF-16 strings are valid Unicode
(by definition), there's no problem there.

However, the problem on Windows is not the underlying file system, but the
Explorer interface. It still uses old legacy encodings, and localises them
in different countries, so it is invariable that people end up with
mojibake file names.


>> Julia's approach is interesting, but it strikes me as somewhat broken
>> as it pretends to do O(1) indexing, but in reality it's still O(n)
> 
> If the underlying encoding is 8-bit, converting it to an O(1) structure
> would still be O(n).

Yes, but you only need to do that once, on input, or at most twice, on input
and output, not on every operation.



-- 
Steven

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

Re: Beginner Python Help

[Ben Finney]

Alan Gabriel  writes:

> I just started out python and I was doing a activity where im trying
> to find the max and min of a list of numbers i inputted.

Welcome to Python!

As a Python beginner you will be interested to join the ‘python-tutor’
forum https://mail.python.org/mailman/listinfo/tutor> which is
focussed specifically to collaborative teaching of beginner Python.

-- 
 \ “If history and science have taught us anything, it is that |
  `\ passion and desire are not the same as truth.” —E. O. Wilson, |
_o__)  _Consilience_, 1998 |
Ben Finney

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

Re: How to waste computer memory?

[alister]

On Thu, 17 Mar 2016 21:37:02 +, alister wrote:

> On Fri, 18 Mar 2016 07:42:30 +1100, Chris Angelico wrote:
> 
>> On Fri, Mar 18, 2016 at 7:31 AM,   wrote:
>>> Rick Johnson  wrote:

 In the event that i change my mind about Unicode, and/or for the sake
 of others, who may want to know, please provide a list of languages
 that *YOU* think handle Unicode better than Python, starting with the
 best first. Thanks.

>>> How about a list of languages that Unicode handles better than ASCII?
>>> Like almost every language *except* English.
>> 
>> Like every language *including* English. You can pretend that ASCII is
>> enough, but you do lose some information.
>> 
>> ChrisA
> 
> as we all seam to have bitten the troll's thread "how to waste computer
> memory"
> give it to an delusion-ed incompetent to play with
> 
> it is now 2016 not 1978, Memory is cheap. plentifully and fast there is
> more than enough to go arround

what is should had added is that there are many methods to reduce memory 
usage but they mostly increase processor load & slow execution
when there is plenty of memory it makes more sense to code for speed even 
if this uses more memory

how are you measuring efficiency speed , memory usage or a combination of 
both?

Define waste if the memory used gets the task completed faster is it 
wasted?



-- 
In 1869 the waffle iron was invented for people who had wrinkled waffles.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: empty clause of for loops

[Steven D'Aprano]

On Thu, 17 Mar 2016 05:05 am, Sven R. Kunze wrote:

> What I don't understand is why Python features "if break, then no else
> clause", but "if empty, then empty clause".
> 
> I found this excellent post:
> https://shahriar.svbtle.com/pythons-else-clause-in-loops

That post describes the motivating use-case for the introduction
of "if...else", and why break skips the "else" clause:


for x in data:
if meets_condition(x):
break
else:
# raise error or do additional processing 


It might help to realise that the "else" clause is misnamed. It should be
called "then":

for x in data:
block
then:
block


The "then" (actually "else") block is executed *after* the for-loop, unless
you jump out of that chunk of code by raising an exception, calling return,
or break.

As a beginner, it took me years of misunderstanding before I finally
understood for...else and while...else, because I kept coming back to the
thought that the else block was executed if the for/while block *didn't*
execute. I couldn't get code with for...else to work right and I didn't
understand why until finally the penny dropped and realised that "else"
should be called "then".



-- 
Steven

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

Bash-like pipes in Python

[Steven D'Aprano]

There's a powerful technique used in shell-scripting languages like bash:
pipes. The output of one function is piped in to become the input to the
next function.

According to Martin Fowler, this was also used extensively in Smalltalk:

http://martinfowler.com/articles/collection-pipeline/

and can also be done in Ruby, using method chaining.

Here is a way to do functional-programming-like pipelines to collect and
transform values from an iterable:

https://code.activestate.com/recipes/580625-collection-pipeline-in-python/

For instance, we can take a string, extract all the digits, convert them to
ints, and finally multiply the digits to give a final result:

py> from operator import mul
py> "abcd12345xyz" | Filter(str.isdigit) | Map(int) | Reduce(mul)
120


(For the definitions of Filter, Map and Reduce, see the code at the
ActiveState recipe, linked above). In my opinion, this is much nicer
looking that the standard Python `filter`, `map` and `reduce`:

py> reduce(mul, map(int, filter(str.isdigit, "abcd12345xyz")))
120

as this requires the operations to be written in the opposite order to the
order that they are applied.



-- 
Steven

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

Re: Case Statements

[Chris Angelico]

On Thu, Mar 17, 2016 at 5:29 PM, Steven D'Aprano
 wrote:
> I don't think that property is a similar situation. I think what happens
> here is that the first call to property sets:
>
> # @property def x...
> x = property(x)
>
> Then the second decorator does:
>
> # @x.setter def x...
> x = x.setter(x)
>
> which replaces x with a brand new property object.

Okay. Let's try this.

>>> class Demo:
... @property
... def x(self):
... print("Getting x")
... return 42
... @x.setter
... def x(self, value):
... print("Setting x to", value)
...
>>> d = Demo()
>>> d.x
Getting x
42
>>> d.x = 1
Setting x to 1


Decorators work. Now let's try NOT using decorators.

>>> class Demo:
... def x(self):
... print("Getting x")
... return 42
... x = property(x)
... def x(self, value):
... print("Setting x to", value)
... x = x.setter(x)
...
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 8, in Demo
AttributeError: 'function' object has no attribute 'setter'


Since the 'def' line bound the undecorated function to the name 'x',
the decoration underneath *fails*. The only way this could work would
be with a temporary name for either the new function or the decorator:

>>> class Demo:
... def x(self):
... print("Getting x")
... return 42
... x = property(x)
... decorator = x.setter
... def x(self, value):
... print("Setting x to", value)
... x = decorator(x)
... del decorator
...
>>> d = Demo()
>>> d.x
Getting x
42
>>> d.x = 1
Setting x to 1

This is how CPython implements this (it evaluates the decoration
expressions first, leaving them on the stack, then creates the
function, then calls the decorators), but I don't see anywhere that
this is guaranteed in the docs either - the only way I know this is
current behaviour is from trying it (with dis.dis). The documented
equivalence simply doesn't work.

Note, by the way, that I am not in any way criticising the *behaviour*
here. I don't think anything needs to be changed as regards
functionality. And it's not even that big an issue as regards
documentation. It's mainly just an esoteric curiosity.

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

Re: sobering observation, python vs. perl

[Rustom Mody]

On Thursday, March 17, 2016 at 11:24:00 PM UTC+5:30, BartC wrote:
> On 17/03/2016 17:25, Charles T. Smith wrote:
> > On Thu, 17 Mar 2016 19:08:58 +0200, Marko Rauhamaa wrote:
> 
> >> my $str = "I have a dream";
> >> my $find = "have";
> >> my $replace = "had";
> >> $find = quotemeta $find; # escape regex metachars if present
> >> $str =~ s/$find/$replace/g;
> >> print $str;
> >>
> >> with Python:
> >>
> >> print("I have a dream".replace("have", "had"))
> 
> > Uh... that perl is way over my head.  I admit though, that perl's
> > powerful substitute command is also clumsy.  The best I can do
> > right now is:
> >
> > $v =  "I have a dream\n";
> > $v =~ s/have/had/;
> > print $v
> 
> I was going to suggest just using a function. But never having coded in 
> Perl before, I wasn't expecting something this ugly:
> 
> sub replacewith{
> $s = $_[0];
> $t = $_[1];
> $u = $_[2];

I think [untested] you can shorten those 3 lines to:
($s, $t, $u) = @_ ;

> $s =~ s/$t/$u/;
> return $s;
> }
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to waste computer memory?

[Ian Kelly]

On Fri, Mar 18, 2016 at 6:37 AM, Chris Angelico  wrote:
> On Fri, Mar 18, 2016 at 10:46 PM, Steven D'Aprano  wrote:
>> Technically, UTF-8 doesn't *necessarily* imply indexing is O(n). For
>> instance, your UTF-8 string might consist of an array of bytes containing
>> the string, plus an array of indexes to the start of each code point. For
>> example, the string:
>>
>> “abcπßЊ•𒀁”
>>
>> (including the quote marks) is 10 code points in length and 22 bytes as
>> UTF-8. Grouping the (hex) bytes for each code point, we have:
>>
>> e2809c 61 62 63 cf80 c39f d08a e280a2 f0928081 e2809d
>>
>> so we could get a O(1) UTF-8 string by recording the bytes (in hex) plus the
>> indexes (in decimal) in which each code point starts:
>>
>> e2809c616263cf80c39fd08ae280a2f0928081e2809d
>>
>> 0 3 4 5 6 8 10 12 15 19
>>
>> but (assuming each index needs 2 bytes, which supports strings up to 65535
>> characters in length), that's actually LESS memory efficient than UTF-32:
>> 42 bytes versus 40.
>
> A lot of strings will have no more than 255 non-ASCII characters in
> them. (For example, all strings which no more than 255 total
> characters.) You could store, instead of the indexes themselves, a
> series of one-byte offsets:
>
> e2809c616263cf80c39fd08ae280a2f0928081e2809d
> 0 2 2 2 2 3 4 5 7 10
>
> Locating a byte based on its character position is still O(1); you
> look up that position in the offset table, add that to your original
> character position, and you have the byte location. For strings with
> too many non-ASCII codepoints, you'd need some other representation,
> but at that point, it might be worth just switching to UTF-32.

So this uses approximately twice as much memory as the FSR and still
requires switching on some form of character width in the
implementation? Yeah, I don't think the RUE is going to go for that.
8-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: retrieve key of only element in a dictionary (Python 3)

[Larry Martell]

On Fri, Mar 18, 2016 at 5:33 PM, Fillmore  wrote:
>
> I must be missing something simple, but...
>
> Python 3.4.0 (default, Apr 11 2014, 13:05:11)
> [GCC 4.8.2] on linux
> Type "help", "copyright", "credits" or "license" for more information.
 d = dict()
 d['squib'] = "007"
 # I forget that 'squib' is my key to retrieve the only element in d
> ...
 type(d.items())
> 
 key = d.items()[0]
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: 'dict_items' object does not support indexing
 key,_ = d.items()
> Traceback (most recent call last):
>   File "", line 1, in 
> ValueError: need more than 1 value to unpack
 key,b = d.items()
> Traceback (most recent call last):
>   File "", line 1, in 
> ValueError: need more than 1 value to unpack
 print(d.items())
> dict_items([('squib', '007')])
 print(d.items()[0])
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: 'dict_items' object does not support indexing

>
> what am I missing? I don't want to iterate over the dictionary.
> I know that there's only one element and I need to retrieve the key

list(d.keys())[0]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: empty clause of for loops

[Palpandi]

On Wednesday, March 16, 2016 at 3:53:48 PM UTC+5:30, Sven R. Kunze wrote:
> Hi,
> 
> a colleague of mine (I write this mail because I am on the list) has the 
> following issue:
> 
> 
> for x in my_iterable:
>  # do
> empty:
>  # do something else
> 
> 
> What's the most Pythonic way of doing this?
> 
> Best,
> Sven

You can do like this.

if not my_iterable:

for x in my_iterable:

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

Re: Replace weird error message?

[Terry Reedy]

On 3/16/2016 2:53 PM, Ben Finney wrote:

"the.gerenuk--- via Python-list"  writes:


The following error message, makes it a bit hard to understand what went wrong


"{:02}".format("1")

Traceback (most recent call last):
   File "", line 1, in 
ValueError: '=' alignment not allowed in string format specifier


Meaning that the ‘str.format’ mini-language parser has decided on the
alignment specifier “=”. It's chosen that because:

 Preceding the width field by a zero ('0') character enables
 sign-aware zero-padding for numeric types. This is equivalent to a
 fill character of '0' with an alignment type of '='.

 https://docs.python.org/3/library/string.html#formatspec>

Nothing in the error message indicates why “'=' alignment” is relevant,
and it does not appear in the code.


Do you think some better error message should be used?


Yes, I think that error message needs to be improved. Please file a bug
report in Python's issue tracker https://bugs.python.org/>.


There already is a closed doc issue, which I am going to reopen to 
further revise the doc. https://bugs.python.org/issue15660



For example a hint that "0" does work for the given argument.


I suggest: “zero-padding only allowed for numeric types, not 'str'”.


As someone else said, not true.

The problem with changing the exception message is that the formatter 
does not know at the point of the exception whether the alignment was 
set to '=' explicitly by the user or implicitly by the use of '0' fill.


--
Terry Jan Reedy


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

Re: Case Statements

[Marko Rauhamaa]

BartC :

> Yes, a few scripting languages can do interesting things with switch or
> case statements. Perl for example (where I think it is created out other
> language features, but it looks a regular part of the syntax).
>
> Even Ruby has one. It doesn't do anything 'sexy' with it, but it does
> have this:
>
>  case
>  when this
> 
>  when that
> 
>  when other
> ...
>  end

That's a different topic.

> which is exactly equivalent to if this... elif that... (when the tests
> are ordered), with one difference:
>
> Each test starts with "when", instead of "if" for the first and "elif"
> for subsequent ones. That makes it easier to reorder tests, temporarily
> comment out the first test, copy a test from elsewhere, insert a new
> first test (you get the idea).

That is no different from a chained if/elif.

Scheme has this:

   (case (* 2 3)
 ((2 3 5 7)
  'prime)
 ((1 4 6 8 9)
  'composite)
 (else
  'unknown))

It has something better than C even:

   (case (die10)
 ((1 3 5 7 9)
  => (lambda (n)
   n))
 (else
  => (lambda (n)
   (/ n 2

which maps 1, 3, 5, 7 and 9 onto themselves but halves 2, 4, 6, 8 and
10.

As for a chained if/elif, Scheme as "cond:"

   (cond
((windy?)
 (fly-kite))
((shining? sun)
 (go-out))
((raining?)
 (play-soccer))
(else
 (read-book)))

which also has a "=>" variant:

   (cond
((best-selling-book (this-year))
 => (lambda (book)
  (read book)))
(else
 (play wii pes08)))


Marko

PS What is a "scripting language?"
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: WP-A: A New URL Shortener

[Daniel Wilcox]

=D

On Wed, Mar 16, 2016 at 11:16 AM, Rick Johnson  wrote:

> On Wednesday, March 16, 2016 at 7:02:16 AM UTC-5, Daniel Wilcox wrote:
> > I dare say I'm with Rick on this point[...]
>
> Contrary to "pseudo popular belief", it's perfectly okay to
> agree with Rick (from time to time). Hey, even a stopped
> clock is correct twice a day!
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: WP-A: A New URL Shortener

[Dan Sommers]

On Thu, 17 Mar 2016 23:08:24 +1100, Chris Angelico wrote:

> So you would need to come up with a system that's distributed (such
> that one computer's inaccessibility doesn't bring everything down) and
> permanent (keep on circulating that information!). It could be a
> rather fun problem to tackle.

If I want NNTP and long retention times, I know where to find them!  :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to waste computer memory?

[Terry Reedy]

On 3/18/2016 12:44 PM, Steven D'Aprano wrote:


Hmmm, well, nobody uses UCS-2 any more, since that only covers the first
65536 code points.


Unfortunately, tcl, or at least tk, still uses ucs-2.  Hence tkinter and 
applications thereof, like IDLE, can only display BMP code points. A 
real nuisance.


--
Terry Jan Reedy

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

Re: empty clause of for loops

[Mark Lawrence]

On 16/03/2016 13:25, alister wrote:

On Wed, 16 Mar 2016 11:47:31 +0100, Peter Otten wrote:


Sven R. Kunze wrote:


Hi,

a colleague of mine (I write this mail because I am on the list) has
the following issue:


for x in my_iterable:
  # do
empty:
  # do something else


What's the most Pythonic way of doing this?


What would you expect?


class Empty(Exception): pass

...

def check_empty(items):

... items = iter(items)
... try:
... yield next(items)
... except StopIteration:
... raise Empty ... yield from items ...

try:

...for item in check_empty("abc"): print(item)
... except Empty: print("oops")
...
a
b
c

try:

...for item in check_empty(""): print(item)
... except Empty: print("oops")
...
oops

I'm kidding, of course. Keep it simple and use a flag like you would in
any other language:

empty = True:
for item in items:
 empty = False ...
if empty:
 ...


or even use the loop variable as the flag

item=None
for item in items:
#do stuff
if ex is None:
#do something else



Did you test this? :)


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Replace weird error message?

[the.gerenuk--- via Python-list]

The following error message, makes it a bit hard to understand what went wrong

>>> "{:02}".format("1")
Traceback (most recent call last):
  File "", line 1, in 
ValueError: '=' alignment not allowed in string format specifier

(this can happen easily if you read in text files and forget to convert)

Do you think some better error message should be used?

For example a hint that "0" does work for the given argument.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to waste computer memory?

[Ian Kelly]

On Thu, Mar 17, 2016 at 1:21 PM, Rick Johnson
 wrote:
> In the event that i change my mind about Unicode, and/or for
> the sake of others, who may want to know, please provide a
> list of languages that *YOU* think handle Unicode better than
> Python, starting with the best first. Thanks.

jmf has been asked this before, and as I recall he seems to feel that
UTF-8 should be used for all purposes, ignoring the limitations of
that encoding such as that indexing becomes a O(n) operation. He has
pointed at Go as an example of a language wherein Unicode "just
works", although I think that others do not necessarily agree [1].

He also seems to have a strange notion of the meaning of the word
"buggy". He frequently uses that word to describe the Python 3.3
Unicode implementation, although he can't seem to demonstrate any
actual bugs. Instead, he points at cherry-picked micro-benchmarks that
show Python's old "narrow" Unicode implementation (which did not
properly support SMP characters, unlike the "wide" implementation
which was a much greater memory hog than the version he's now
complaining about) outperforming the PEP-393 implementation while
completely ignoring any real-world benchmarks.

[1] https://coderwall.com/p/k7zvyg/dealing-with-unicode-in-go
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: DSLs in perl and python (Was sobering observation)

[Rustom Mody]

On Friday, March 18, 2016 at 4:17:06 AM UTC+5:30, MRAB wrote:
> Stick an "x" on the end of the regex: /something/x or s/old/new/x.

Thanks!

Is there somewhere a regexp 'introspection' API/capability available?

ie if the re looks like
rexp = r"""
# DSL (instantiation) for describing NYSE symbology
^
(?P   [A-Z]*) # The base scrip
(?P [.+-])? # Series type char
(?P  [A-Z])? # Series
(?P [#])?   # issued char indicator
$# Thats all (there should be!)
"""

I would like to know that the named-groups are
{scrip, serchar, series, issued}
without doing match/search etc

That way then the same DSL could be used for quite different regexps

IOW I would like to generalize the code:

g = m.group
scrip, serchar, series, issuedc = g('scrip'), g('serchar'), g('series'), 
g('issuedc')

The scrip, serchar, series etc need not be local vars; 
a dict is fine/preferable
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to waste computer memory?

[Chris Angelico]

On Sat, Mar 19, 2016 at 2:26 AM, Marko Rauhamaa  wrote:
> Michael Torrie :
>
>> On 03/18/2016 02:26 AM, Jussi Piitulainen wrote:
>>> I think Julia's way of dealing with its strings-as-UTF-8 [2] is more
>>> promising. Indexing is by bytes (1-based in Julia) but the value at a
>>> valid index is the whole UTF-8 character at that point, and an
>>> invalid index raises an exception.
>>
>> This seems to me to be a leaky abstraction.
>
> It may be that Python's Unicode abstraction is an untenable illusion
> because the underlying reality is 8-bit and there's no way to hide it
> completely.
>

The underlying reality is 1-bit. Or maybe the underlying reality is
actually electrical signals that don't even have a clear definition of
"bits" and bounce between two states for a few fractions of a second
before settling. And maybe someone's implementing Python on the George
Banks Kite CPU, which consists of two cents' worth of paper and
string, on which text is actually represented by glyph. They're all
equally valid notions of "underlying reality".

Text is an abstract concept, just as numbers are. You fundamentally
cannot represent the notion of "three" in a computer; what you'll
generally do is encode that in some way. C does this by encoding that
in a machine word, then storing the machine word in memory, either
least significant byte lowest in memory, or the other way around.
Congratulations, C! You've already made two conflicting encodings for
integers, and you still have to predeclare a maximum representable
value. If you go for arbitrary-precision integers, there are a whole
lot more ways to encode them. GMP has a bunch of tweakables like
"number of nail bits", or you can go for a simple variable-length
integer that has seven bits of payload per byte and sets the high bit
if there are more bytes to read (and again, you have to figure out
whether that's little-endian or big-endian), or you can go for a more
complex scheme.

Python's Unicode abstraction *never* leaks information about how it's
stored in memory [1] [2]; a Unicode string in Python consists of a
series of codepoints in a well-defined order. This is exactly what you
would expect of a system in which codepoints are fundamental objects
that can truly be represented directly; if you can prove, from within
Python, that the interpreter uses bytes to represent text, I'd be
extremely surprised.

ChrisA

[1] Not since 3.3, at least. 2.7 narrow builds (eg on Windows) can
leak the UTF-16 level, but not further than that.
[2] Well, you might be able to figure stuff out based on timings. Only
in cryptography have I ever heard performance treated as a leak.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: sobering observation, python vs. perl

[Anders J. Munch]

Charles T. Smith:

I've really learned to love working with python, but it's too soon
to pack perl away.  I was amazed at how long a simple file search took
so I ran some statistics:


Write Python in pythonic style instead of translated-from-Perl style, and the 
tables are turned:


$ cat find-rel.py
| import sys
| def main():
| for fn in sys.argv[1:]:
| tn = None
| with open(fn, 'rt') as fd:
| for line in fd:
| if ' is ready' in line:
| tn = line.split(' is ready', 1)[0]
| elif 'release_req' in line:
| print tn
| main()


$ time python find-rel.py *.out
real0m0.647s
user0m0.616s
sys0m0.029s

$ time perl find-rel.pl *.out
real0m0.935s
user0m0.910s
sys0m0.023s

I don't have your log files and my quickly assembled test file doesn't actually 
contain the phrase 'release_req', so my results may be misleading. Perhaps 
you'll try it and post your results?


regards, Anders

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

Re: sobering observation, python vs. perl

[Ethan Furman]

On 03/17/2016 09:36 AM, Charles T. Smith wrote:


Yes, your point was to forgo REs despite that they are useful.
I could have thought the search would have been better as:

 'release[-.:][Rr]eq'

or something else ... you're in a "defend python at all costs!" mode.


No, I'm in the "don't try to write  in Python" mode, and 
"don't use 10lb sledge when 6oz hammer will do" mode:



# using `in` and printing line as each is found
real0m1.703s
user0m0.184s
sys 0m0.260s

# using `in` and printing lines at the end
real0m0.217s
user0m0.112s
sys 0m0.068s

# using 're' and printing lines at the end
real0m0.608s
user0m0.516s
sys 0m0.060s


As you can see, how you print has a huge impact.  Hopefully you also 
noticed that using `re` when `in` would do made the script 3 times slower.



# using `in` code
import sys
found = []
for fn in sys.argv[1:]:
   with open(fn) as fh:
  for line in fh:
 if 'timezone' in line:
found.append(line)
print ''.join(found)

# using `re` code
import sys
import re
found = []
for fn in sys.argv[1:]:
   with open(fn) as fh:
  for line in fh:
 if re.search('timezone', line):
found.append(line)
print ''.join(found)


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

Re: empty clause of for loops

[Tim Chase]

On 2016-03-16 16:53, Peter Otten wrote:
> > item=None
> > for item in items:
> > #do stuff
>   if item is None:
> > #do something else
> 
> I like that better now I see it.

The only problem with that is if your iterable returns None as the
last item:

  items = ["Something here", None]
  item = None
  for item in items:
print(repr(item))
  if item is None:
print("Empty iterable") # wait, no it's not!

You'd have to use a sentinel like Ruud mentions further up-list:

  x = sentinal = object()
  for x in sequence:
print(repr(x))
  if x is sentinal:
print("Empty iterable")

-tkc




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

Re: Replace weird error message?

[Ben Finney]

"the.gerenuk--- via Python-list"  writes:

> The following error message, makes it a bit hard to understand what went wrong
>
> >>> "{:02}".format("1")
> Traceback (most recent call last):
>   File "", line 1, in 
> ValueError: '=' alignment not allowed in string format specifier

Meaning that the ‘str.format’ mini-language parser has decided on the
alignment specifier “=”. It's chosen that because:

Preceding the width field by a zero ('0') character enables
sign-aware zero-padding for numeric types. This is equivalent to a
fill character of '0' with an alignment type of '='.

https://docs.python.org/3/library/string.html#formatspec>

Nothing in the error message indicates why “'=' alignment” is relevant,
and it does not appear in the code.

> Do you think some better error message should be used?

Yes, I think that error message needs to be improved. Please file a bug
report in Python's issue tracker https://bugs.python.org/>.

> For example a hint that "0" does work for the given argument.

I suggest: “zero-padding only allowed for numeric types, not 'str'”.

-- 
 \ “In economics, hope and faith coexist with great scientific |
  `\  pretension and also a deep desire for respectability.” —John |
_o__)Kenneth Galbraith, 1970-06-07 |
Ben Finney

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

Re: How to waste computer memory?

[Marko Rauhamaa]

Random832 :

> On Fri, Mar 18, 2016, at 20:55, Chris Angelico wrote:
>> On Sat, Mar 19, 2016 at 9:03 AM, Marko Rauhamaa  wrote:
>> > Also, special-casing '\0' and '/' is
>> > lame. Why can't I have "Results 1/2016" as a filename?
>> 
>> Would you be allowed to have a directory named "Results 1" as well?
>
> If I were designing a new operating from scratch and didn't have to be
> compatible with anything, I would probably have pathnames be tuples of
> strings (maybe represented at the low level with percent-escaping),
> rather than having a directory separator.

Speaking of the low level, the classic UNIX file system doesn't make use
of pathnames. Rather, the files are nameless. They are identified by the
device (= file system) number plus the inode number.

Some files are directories, dir objects if you will, that map filenames
to inode numbers. The file system enforces the limitation that the
filenames (directory keys) cannot contain '\0' or '/' ASCII characters.
The entries of the directory are called (hard) links.

A pathname is a clumsy proxy for a file because the file system may be
modified between references through renames or deletions. What you'd
want is reference object that maintains a reference count on the inode.
Or course, you could create a hard link on the fly, but the operating
system doesn't clear the link automatically when the client process goes
away nor does it prevent other processes from tampering with the link.

You could open the file and use the file descriptor as such a reference
object. However, the process may not have access rights to open the
file. UNIX forces you to open a file with O_RDONLY, O_WRONLY or O_RDWR;
you'd need an O_REF option that doesn't allow you any I/O access to the
file but allows you to refer to a file.


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

Re: How to waste computer memory?

[Chris Angelico]

On Sat, Mar 19, 2016 at 6:49 PM, Marko Rauhamaa  wrote:
> Speaking of the low level, the classic UNIX file system doesn't make use
> of pathnames. Rather, the files are nameless. They are identified by the
> device (= file system) number plus the inode number.

Not entirely fair. A file system has directories in it, which have
names in them referencing other inodes. So while you can get to the
contents of the file given only its inode, but the path names are very
much a part of the file system too.

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

Re: from a module return a class

[Rick Johnson]

On Thursday, March 17, 2016 at 1:24:10 PM UTC-5, Laurent Pointal wrote:
> So the error: SyntaxError: 'return' outside function

>>> return
SyntaxError: 'return' outside function
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to waste computer memory?

[Steven D'Aprano]

On Sat, 19 Mar 2016 08:08 am, Chris Angelico wrote:

> On Sat, Mar 19, 2016 at 8:02 AM, Marko Rauhamaa  wrote:
>> Chris Angelico :
>>> On Sat, Mar 19, 2016 at 2:26 AM, Marko Rauhamaa 
>>> wrote:
 It may be that Python's Unicode abstraction is an untenable illusion
 because the underlying reality is 8-bit and there's no way to hide it
 completely.
>>>
>>> The underlying reality is 1-bit. Or maybe the underlying reality is
>>> actually electrical signals that don't even have a clear definition of
>>> "bits" and bounce between two states for a few fractions of a second
>>> before settling. And maybe someone's implementing Python on the George
>>> Banks Kite CPU, which consists of two cents' worth of paper and
>>> string, on which text is actually represented by glyph. They're all
>>> equally valid notions of "underlying reality".
>>>
>>> Text is an abstract concept, just as numbers are.
>>
>> The question is how tenable the illusion is. If the OS gave the
>> appropriate guarantees (say, all pathnames are encoded Unicode strings),
>> the abstraction could be maintained. Unfortunately, the legacy shines
>> through making you wonder if Python has overreached prematurely with its
>> Unicode HAL.
> 
> The problem is not Python's Unicode strings, then. The problem is the
> notion that path names are text. If they're text, they should be
> exclusively text (although, for low-level efficiency, they're more
> likely to be defined as "valid UTF-8 sequences" rather than "sequences
> of Unicode codepoints"); since they're not, they are fundamentally
> bytes. But that's not a problem with Python - it's a problem with the
> file system.


One thing that NTFS gets right is that all path names are guaranteed to be
well-formed, valid Unicode. I believe that they are stored in UTF-16, and
unlike the ext file systems used on Linux, they are not arbitrary bytes.

I believe that HFS+ on Apple Macs goes one step further and guarantees that
paths are always fully normalised, so that it's impossible to have (e.g.)
two files ã (U+00E3 LATIN SMALL LETTER A WITH TILDE) and ã (U+0061 LATIN
SMALL LETTER A + U+0303 COMBINING TILDE) in the same directory.

Unfortunately, backwards compatibility is holding Linux file systems back...



-- 
Steven

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

Re: sobering observation, python vs. perl

[Charles T. Smith]

On Thu, 17 Mar 2016 18:34:06 +0200, Marko Rauhamaa wrote:

> n-vs-perl-performance


Okay, that was interesting.

Actually, I saw a study some years ago that concluded that python
could be both slower and faster than perl, but that perl had much
less deviation than python.  I took that and accepted it, but
was surprised now that in exactly the field of application that I've
traditionally used perl, it really is better, er... faster.

Furthermore, the really nice thing about python is its OO, but
I've really neglected looking into that with perl's OO capabilities.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Case Statements

[Chris Angelico]

On Thu, Mar 17, 2016 at 4:45 PM, Gregory Ewing
 wrote:
> Steven D'Aprano wrote:
>>
>> On Thu, 17 Mar 2016 11:31 am, Chris Angelico wrote:
>>
>>>orig = globals()[cls.__name__]
>>
>>
>> I wouldn't want to rely on it working with decorator syntax either. Even
>> if
>> it does now, I'm not sure that's a language guarantee.
>
>
> The following idiom relies on similar behaviour:
>
> @property
> def x(self):
> return self._x
>
> @x.setter
> def x(self, value):
> self._x = value
>
> That's taken from the official docs, so I don't think
> this is likely to change any time soon.

Ooh, didn't think of that. So maybe it's a language guarantee that
hasn't been written down somewhere, and the "func = deco(func)"
version is a known-imperfect-equivalent, same as "for x in iter: yield
x" is an imperfect equivalent for "yield from iter".

It would be possible to support @x.setter by simply guaranteeing that
the decorator expression is evaluated prior to the function creation:

_tmp = x.setter # but without using an actual name
def x(self, value):
self._x = value
x = _tmp(x)

But I doubt the language needs to go to this level of finickiness. In
fact, all it really needs is an acknowledgement that there are corner
cases:

http://bugs.python.org/issue26576

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

Re: How to waste computer memory?

[Chris Angelico]

On Sat, Mar 19, 2016 at 8:28 AM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> The problem is not Python's Unicode strings, then. The problem is the
>> notion that path names are text. If they're text, they should be
>> exclusively text (although, for low-level efficiency, they're more
>> likely to be defined as "valid UTF-8 sequences" rather than "sequences
>> of Unicode codepoints"); since they're not, they are fundamentally
>> bytes. But that's not a problem with Python - it's a problem with the
>> file system.
>
> The file system does not have a problem. Python has a problem because it
> tries to present pathnames as Unicode strings, which isn't always
> possible.

But what does a file name *mean*? If it has no meaning, we should
simply use a hierarchical tree of IDs. The point of a file *name* is
that it has meaning to a human, which implies that they carry text,
not bytes. So I maintain that the problem here is with the file
system; it permits (for historical reasons) arbitrary byte sequences.

If I were building an entire OS ecosystem from scratch today, I'd
probably do a lot of things with a hybrid system of documented meaning
atop implementation-detail APIs. In this particular case, I would
define the API in terms of byte sequences, but clearly documenting
that these byte sequences are to be understood to mean text strings,
and thus must be valid UTF-8. It's still efficient (moving bytes
around the kernel is easier than having heaps of text<->bytes
transitions), but it allows future changes to depend on all non-broken
usage fitting this pattern.

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

Re: monkey patching __code__

[Ned Batchelder]

On Friday, March 18, 2016 at 10:33:46 AM UTC-4, Sven R. Kunze wrote:
> On 18.03.2016 15:23, Ian Kelly wrote:
> > On Fri, Mar 18, 2016 at 7:47 AM, Ian Kelly  wrote:
> >> Your patched version takes two extra arguments. Did you add the
> >> defaults for those to the function's __defaults__ attribute?
> > And as an afterthought, you'll likely need to replace the function's
> > __globals__ with your own as well.
> 
> Thanks again. :-)
> 
> Again, why would it make sense for those dunder attributes to be part of 
> the function but not of the code object?

Code objects are immutable, and marshal'able (a .pyc file is basically
just a magic-numbered, time-stamped, marshalled code object for the
module).  Marshal can't marshal arbitrary Python objects.

Functions are mutable, and constructed at run-time, so can reference
arbitrary Python objects.  Since you want default values to possibly
be user-defined Python objects, the defaults are on the function, not
the code object.

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

Re: Case Statements

[Chris Angelico]

On Thu, Mar 17, 2016 at 12:54 PM, Steven D'Aprano  wrote:
> On Thu, 17 Mar 2016 11:31 am, Chris Angelico wrote:
>
>> Yes... in theory. But try rewriting my example to avoid decorator
>> syntax. It won't work, because of this line:
>>
>> orig = globals()[cls.__name__]
>
> That's a nasty, dirty piece of code, and I hope you are thoroughly ashamed
> of having written it :-)

No, I am not ashamed of having written it. The file it's in is called
"evil.py" and it exists specifically to showcase bad uses of
decorators :)

>> It depends on the decorator being run before the name actually gets
>> bound - which means the previous class is available to the decorator.
>> You can't do that without decorator syntax, or messing around with
>> multiple names.
>
>
> I wouldn't want to rely on it working with decorator syntax either. Even if
> it does now, I'm not sure that's a language guarantee.

That's the thing, though. It's not a guarantee, yet it does work in
every Python interpreter that I tried it in. And that puts it on par
with dictionary iteration order - people will end up depending on it.
So while it's definitely not wise to deliberately depend on this (and
believe you me, there is nothing like this in any of my production
code!!), it's entirely possible that there's code out in the wild that
unwittingly does.

Anyway, it's just a fun thing to bring out when people start talking
about decorator equivalence. And even experienced Pythonistas can be
confused by it - I certainly was, when I first saw it. Fun fun.

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

Re: Case Statements

[Mark Lawrence]

On 16/03/2016 13:15, l0r0m0a0...@gmail.com wrote:

What hath I wrought?



The Comfy Chair :)

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: How to waste computer memory?

[Chris Angelico]

On Fri, Mar 18, 2016 at 8:11 AM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> Like every language *including* English. You can pretend that ASCII is
>> enough, but you do lose some information.
>
> Hold it, I'll quickly update my résumé before we resume the
> conversation. What does this exposé expose? At least it gives a coup de
> grâce to ASCII with grace.

I'm so glad I have your coöperation in this.

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

Re: Case Statements

[Steven D'Aprano]

On Thu, 17 Mar 2016 05:48 pm, Chris Angelico wrote:

> On Thu, Mar 17, 2016 at 5:29 PM, Steven D'Aprano
>  wrote:
>> I don't think that property is a similar situation. I think what happens
>> here is that the first call to property sets:
>>
>> # @property def x...
>> x = property(x)
>>
>> Then the second decorator does:
>>
>> # @x.setter def x...
>> x = x.setter(x)
>>
>> which replaces x with a brand new property object.

A slight hitch, as you (Chris) has just identified:

By the time i go to call "x.setter", x has been replaced by "def x". Easily
fixed:

def x(self):
...

t = x = property(x)

def x(self, value):
...

x = t.setter(x)


> Okay. Let's try this.
[...]
> Decorators work. Now let's try NOT using decorators.

You are still using a decorator. You're just not using @ decorator syntax.


 class Demo:
> ... def x(self):
> ... print("Getting x")
> ... return 42
> ... x = property(x)
> ... def x(self, value):
> ... print("Setting x to", value)

Oops, there's the problem. "def x" re-binds the property object, as so this
line:

> ... x = x.setter(x)

fails.

But we can fix it like this:

def x(self):
print("Getting x")
return 42
x = property(x)
def y(self, value):
print("Setting x to", value)
x = x.setter(y)


> Since the 'def' line bound the undecorated function to the name 'x',
> the decoration underneath *fails*. The only way this could work would
> be with a temporary name for either the new function or the decorator:

Right! We seem to be repeating each other each other each other each other
each other each other.


> This is how CPython implements this (it evaluates the decoration
> expressions first, leaving them on the stack, then creates the
> function, then calls the decorators), but I don't see anywhere that
> this is guaranteed in the docs either - the only way I know this is
> current behaviour is from trying it (with dis.dis). The documented
> equivalence simply doesn't work.

It does work. You just have to be careful to not garbage collect objects
before you can use them :-)


> Note, by the way, that I am not in any way criticising the *behaviour*
> here. I don't think anything needs to be changed as regards
> functionality. And it's not even that big an issue as regards
> documentation. It's mainly just an esoteric curiosity.

I agree with that. It's an interesting corner case in the application of
decorators.




-- 
Steven

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

Re: Exception from pyd methods

[dieter]

Palpandi  writes:
> I am using methods from pyd files. At some cases, it is throwing some error 
> messages in the console.
>
> When I use try.. except.. I am getting only the exception name.
> Not able to catch the entire error message.
>
> How do I get the the entire error message printed in the console?

You may have no chance: "*.pyd" files usually contain functions
defined in "C". If the author of such a function decided to print
a message rather than put it into an exception, then it may be difficult
to get at the message.

If the function author write the message to "sys.stderr" or
"sys.stdout" with standard Python file operations, then you
might be able to get at the message by replacing "sys.stderr/out"
with a file object of your own. But this is first not sure and
second very nasty.

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

Re: How to waste computer memory?

[Chris Angelico]

On Sat, Mar 19, 2016 at 7:22 PM, Marko Rauhamaa  wrote:
> Not all files have pathnames. Those that do have numerous pathnames. You
> can't tell by looking at a file what pathnames, if any, it might have.
> You need an exhaustive, recursive search of the file system for the
> reverse mapping.
>
> If you execute the commands:
>
>echo hello >hello
>rm hello
>
> You don't know for sure if the file you removed was the file you created
> on the previous line.

Not all objects in Python have names bound to them. Those that do may
have multiple. You can't tell, by looking at an object, what pathnames
it has. You need an exhaustive, recursive search of all namespaces for
the reverse mapping.

If you execute the commands:

hello = re.compile("[Hh][Ee][Ll][Ll][Oo]")
hello.match(msg)

you don't know for sure if the object you called a method on was the
one you created on the previous line.

So are object names not part of Python?

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

Re: Fetch Gmail Archieved messages

[Rick Johnson]

On Friday, March 18, 2016 at 9:19:34 AM UTC-5, Arshpreet Singh wrote:
> On Friday, 18 March 2016 11:14:44 UTC+5:30, Rick Johnson  wrote:
> 
> > #
> > # BEGIN CODE
> > #
> > import imaplib
> > 
> > def inbox_week():
> > emailAddress = '...@gmail.com'
> > emailPassword = 'mypassword'
> > # START ADDING CODE HERE
> > #
> > # END CODE
> > #
> 
> Well I am asking for real help.(!suggestions)

I gave you "real help". 

What you want me to do -- write the code for you? Sorry, but Python-list is not 
a soup kitchen for destitute code. Neither is it a triage center were you can 
bring your sick code, drop it at the door, and say: "Here, fix this, i'm going 
to the bar".  

Where is your traceback? 

Does your code run without raising Errors?

Why did you create a loop, simply to iterate over a list-literal containing  
one value?

At this point, i can't determine if you're trolling or serious...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: empty clause of for loops

[Terry Reedy]

On 3/16/2016 11:17 AM, Sven R. Kunze wrote:

On 16.03.2016 16:02, Tim Chase wrote:



Does it annoy me when I have to work in other languages that lack
Python's {for/while}/else functionality?  You bet.


I can imagine that. Could you describe the general use-case? From what I
know, "else" is executed when you don't "break" the loop. When is this
useful?


When one wants to know if the iterable contained an exceptional item or 
not or when one wants to know if the iterator is exhausted or not.


--
Terry Jan Reedy

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

Re: retrieve key of only element in a dictionary (Python 3)

[Steven D'Aprano]

On Sat, 19 Mar 2016 12:36 pm, Chris Angelico wrote:

> So unpacking will give you those keys - in an arbitrary order. Of
> course, you don't care about the order when there's only one.

But what if you want the key in reverse order?

# Standard order
[key] = mydict

# Reverse order
[yɘʞ] = mydict





-- 
Steven

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

Re: How to waste computer memory?

[Steven D'Aprano]

On Sat, 19 Mar 2016 01:30 pm, Random832 wrote:

> On Fri, Mar 18, 2016, at 20:55, Chris Angelico wrote:
>> On Sat, Mar 19, 2016 at 9:03 AM, Marko Rauhamaa  wrote:
>> > Also, special-casing '\0' and '/' is
>> > lame. Why can't I have "Results 1/2016" as a filename?
>> 
>> Would you be allowed to have a directory named "Results 1" as well?
> 
> If I were designing a new operating from scratch and didn't have to be
> compatible with anything, I would probably have pathnames be tuples of
> strings (maybe represented at the low level with percent-escaping),
> rather than having a directory separator.


ls -l /home/user/documents/stuff/foo


ls -l "home","user","documents","stuff","foo"


I think users of command line tools and shells will hate you.





-- 
Steven

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

Re: How to waste computer memory?

[Rick Johnson]

On Thursday, March 17, 2016 at 7:52:26 PM UTC-5, Gene Heskett wrote:
> So the obvious question then is, will any of your python code still be 
> running and doing its labor saving and dead on the video frame timing 
> job several times daily, 17 years hence?

Well, let me put it this way folks: As much as like Python,
i must admit that it's staying power will be more aligned
with that of Brittney Spears and Justin Timberlake -- than
the Beatles or the Rolling Stones.

Actually, the range is correct, but the celebrities are
completely wrong!

Python is more like James Marshall Hendrix, Elvis Presley,
Janis Joplin, and Jim Morrison all wrapped-up into one!

"Alien forces" from another dimension, that showed up one
day, transformed rock-n-roll, and then disappeared before we
even knew what the heck happened.

In the not too distant future, there will be vast conspiracy
theories surrounding the demise of Python -- some will say
it was the mob, others the government.

There will be random public sightings, and kooks will claim 
to see the "image of Python" on burnt toast.

Perhaps someone, after attaching suction cups to a stuffed
snake, will enjoy the "commercial interstate success" that 
only Jim Davis knows...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: retrieve key of only element in a dictionary (Python 3)

[Chris Angelico]

On Sat, Mar 19, 2016 at 7:29 PM, Steven D'Aprano  wrote:
> On Sat, 19 Mar 2016 12:36 pm, Chris Angelico wrote:
>
>> So unpacking will give you those keys - in an arbitrary order. Of
>> course, you don't care about the order when there's only one.
>
> But what if you want the key in reverse order?
>
> # Standard order
> [key] = mydict
>
> # Reverse order
> [yɘʞ] = mydict

Unfortunately, Steven, that won't work - you forgot to invert the
brackets. And no, switching them won't work:

]yɘʞ[ = mydict

You need to have actual backward brackets so Python knows you want to
iterate backward through the dictionary, starting with the last value
and proceeding to the first index.

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

Re: How to waste computer memory?

[Chris Angelico]

On Sat, Mar 19, 2016 at 7:38 PM, Steven D'Aprano  wrote:
> ls -l /home/user/documents/stuff/foo
>
>
> ls -l "home","user","documents","stuff","foo"
>
>
> I think users of command line tools and shells will hate you.

You misunderstand him. He doesn't want path names like that. He wants
JSON, remember?

{"command": "ls", "options": ["-l"], "arguments":
[["home","user","documents","stuff","foo"]]}

Of course, if this is too long, you can omit the spaces in between.

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

Re: sobering observation, python vs. perl

[Charles T. Smith]

On Thu, 17 Mar 2016 17:47:55 +0200, Marko Rauhamaa wrote:


> Can't comment on the numbers but the code segments are not quite
> analogous. What about this one:
> 
> #!/usr/bin/env python
> # vim: tw=0
> import sys
> import re
> 
> isready = re.compile("(.*) is ready")
> for fn in sys.argv[1:]:
> tn = None
> with open(fn) as fd:
> for line in fd:
> match = isready.match(line)
> if match:
> tn = match.group(1)
> elif "release_req" in line:
> print tn
> 
> 
> Marko


I need the second check to also be a RE because it's not
separate tokens.  How about this change:

match = isready.match (line)
if match:
tn = match.group(1)
 >  continue

match = relreq.match (line)
if match:
print tn

real0m28.737s
user0m28.538s
sys 0m0.128s

Shaved 2 seconds off.

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

Re: sobering observation, python vs. perl

[Peter Otten]

Charles T. Smith wrote:

> On Thu, 17 Mar 2016 10:52:30 -0500, Tim Chase wrote:
> 
>>> Not saying this will make a great deal of difference, but these two
>> items jumped out at me.  I'd even be tempted to just use string
>> manipulations for the isready aspect as well.  Something like
>> (untested)
> 
> well, I don't want to forgo REs in order to have python's numbers be
> better

As has been said, for simple text processing tasks string methods are the 
preferred approach in Python. I think this is more for clarity than 
performance.

If you need regular expressions a simple way to boost performance may be to 
use the external regex module.

(By the way, if you are looking for a simple way to iterate over multiple 
files use
for line in fileinput.input():
...
)

Some numbers:

$ time perl find.pl data/sample*.txt > r1.txt

real0m0.504s
user0m0.466s
sys 0m0.036s
$ time python find.py data/sample*.txt > r2.txt

real0m2.403s
user0m2.339s
sys 0m0.059s
$ time python find_regex.py data/sample*.txt > r3.txt

real0m0.693s
user0m0.631s
sys 0m0.060s
$ time python find_no_re.py data/sample*.txt > r4.txt

real0m0.319s
user0m0.267s
sys 0m0.048s

Python 3 slows down things:

$ time python3 find_no_re.py data/sample*.txt > r5.txt

real0m0.497s
user0m0.444s
sys 0m0.051s

The scripts:
$ cat find.pl
#!/usr/bin/env perl

while (<>) {
if (/(.*) is ready/) {
$tn = $1;
}
elsif (/release_req/) {
print "$tn\n";
}
}
$ cat find.py
#!/usr/bin/env python
import sys
import re

def main():
isready = re.compile ("(.*) is ready").match
relreq = re.compile (".*release_req").match

tn = ""
for fn in sys.argv[1:]:
with open(fn) as fd:
for line in fd:
match = isready(line)
if match:
tn = match.group(1)
elif relreq(line):
print(tn)

main()

$ cat find_regex.py
#!/usr/bin/env python
import sys
import regex as re
[rest the same as find.py]

$ cat find_no_re.py
#!/usr/bin/env python
import sys

def main():
tn = ""
for fn in sys.argv[1:]:
with open(fn) as fd:
for line in fd:
if " is ready" in line:
tn = line.partition(" is ready")[0]
elif "release_req" in line:
print(tn)

main()

The test data was generated with

$ cat make_test_data.py
#!/usr/bin/env python3
import os
import random
import shutil

from itertools import islice


def make_line_factory(words, line_length, isready):
choice = random.choice

def make_line():
while True:
line = [choice(words)]
length = len(line[0])
while length < line_length:
word = choice(words)
line.append(word)
length += len(word) + 1
if random.randrange(100) < isready:
pos = random.randrange(len(line))
line[pos:pos+1] = ["is", "ready"]
elif random.randrange(100) < isready:
pos = random.randrange(len(line))
line[pos:pos] = ["release_req"]
yield " ".join(line)

return make_line


def main():
import argparse
parser = argparse.ArgumentParser()
parser.add_argument("--words", default="/usr/share/dict/words")
parser.add_argument("--line-length", type=int, default=80)
parser.add_argument("--num-lines", type=eval, default=10**5)
parser.add_argument("--num-files", type=int, default=4)
parser.add_argument("--name-template", default="sample{:0{}}.txt")
parser.add_argument("--data-folder", default="data")
parser.add_argument("--remove-data-folder", action="store_true")
parser.add_argument("--first-match-percent", type=int, default=10)
try:
import argcomplete
except ImportError:
pass
else:
argcomplete.autocomplete(parser)

args = parser.parse_args()

if args.remove_data_folder:
shutil.rmtree(args.data_folder)
os.mkdir(args.data_folder)

with open(args.words) as f:
words = [line.strip() for line in f]

make_line = make_line_factory(
words, args.line_length, args.first_match_percent)()

width = len(str(args.num_files))
for index in range(1, args.num_files+1):
filename = os.path.join(
args.data_folder,
args.name_template.format(index, width))
print(filename)
with open(filename, "w") as f:
for line in islice(make_line, args.num_lines):
print(line, file=f)


if __name__ == "__main__":
main()


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

Re: Bash-like pipes in Python

[Random832]

On Thu, Mar 17, 2016, at 10:36, Chris Angelico wrote:
> This object has a generator/list duality, but if you observe it, it
> collapses to a list. When used interactively, it'd be pretty much the
> same as calling list() as the last step, but in a script, they'd
> operate lazily.
> 
> Quantum computing is here already!

Might as well add the sequence protocol while we're at it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: empty clause of for loops

[Steven D'Aprano]

On Wed, 16 Mar 2016 11:41 pm, André Roberge wrote:

> for x in my_iterable:
># do something
> 
> if not my_iterable:
># do something else


Doesn't work for iterators. Iterators are (in general) always truthy,
whether they are empty or not.



-- 
Steven

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

Re: empty clause of for loops

[André Roberge]

On Wednesday, 16 March 2016 07:23:48 UTC-3, Sven R. Kunze  wrote:
> Hi,
> 
> a colleague of mine (I write this mail because I am on the list) has the 
> following issue:
> 
> 
> for x in my_iterable:
>  # do
> empty:
>  # do something else
> 
> 
> What's the most Pythonic way of doing this?
> 
> Best,
> Sven

for x in my_iterable:
   # do something

if not my_iterable:
   # do something else

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

Re: Case Statements

[BartC]

On 16/03/2016 09:51, Mark Lawrence wrote:

On 16/03/2016 09:35, Antoon Pardon wrote:



So I guess those who would like a case statement in Python can
only hope a core developer gets bitten by a nasty bug while using
one of those ways of simulating switches.



So that core developers can waste their time putting something into the
language that we've done without for 25 years, yes, that strikes me as
extremely worthwhile.



I've noticed that Python doesn't appear to have a way of putting 
separators into numeric literals. (Or if it does, I've no idea how). 
That means being able to write:


a = 1'000'000
b =   239_288
c = 0x7FFF```

depending on what separator is used. Despite waiting for it for 25 
years, would that be worthwhile or not? (And if not, why not? And if it 
is, perhaps other things can be too.)



Of course the change is actually trivial,


The above really is trivial (to anyone already familiar with the 
workings of the byte-code compiler).



as
BartC has all ready pointed out. The work involved is shown here
https://mail.python.org/pipermail/python-dev/2006-June/065827.html


That article appears to try to do without using a new switch byte-code, 
as the author doesn't see the point. My code to implement a 'switch' 
byte-code (for integer expression and constant integer case-expressions) 
is below.


Not shown is the support needed in the byte-code compiler (about 300 
lines in my case as it's a bit fiddly, but it's not a run-time cost).


For a Python version, it might be an idea to make use of the convention 
for constants (all-caps), then a streamlined switch could be on the cards.


global function k_switch:ref void =
int index,n,lower

n := getopnda
lower := getopndb

case sptr^.tag
when tint,ttype then
else
pcerror("switch not int")
esac

index:=(sptr++)^.value-lower

if u32(index)>=u32(n) then# out of range
return ref int((pcptr+n*2+4)^)
else
return ref int((pcptr+index*2+4)^)
fi
end


--
Bartc


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

Re: from a module return a class

[Laurent Pointal]

kevind0...@gmail.com wrote:

> Hello:
> 
> Working with python 2.7.
> 
> I have a module promptUser_PWord  that will prompt a user for their user
> name and pword.  Works fine stand alone.
> I also have a module, genXLS that does a bunch of processing it has worked
> fine for months.  And a class Unamepword define as follows: class
> Unamepword:
> ## 
> ## class to hold user name and pWord for Database
> uName = None
> pWord = None
> def __init__(self, uStr, pStr):
> self.uName = uStr
> self.pWord = pStr
> 
> There are scenarios where running genXLS requires the user to be prompted
> for their user name and password.
> 
> The final line of promptUser_PWord are:
> user_pword =  Unamepword(dbUser, pWord)
> return user_pword
> 
> 
> And in genXLS I have
> ##  prompt the user for a User name a& pWord
> user_pword = promptUser_PWord()
> 
> I get the error
>   File "H:\dev\eclipse\workspace\genXls\src\genXls\promptUser_PWord.py",
>   line 58
> return user_pword
> SyntaxError: 'return' outside function
> 
> 
> Here is my complete newbee question:
>How do I stich these pieces together so the user will be prompted and
>the values (contained in the class Unamepword) will be passed back to
>genXLS ?

Just… define a function (SyntaxError: 'return' outside function).


> The final line of promptUser_PWord become:

user_pword =  Unamepword(dbUser, pWord)
def get_user_pword():
 return user_pword

and call get_user_pword() from within genXLS:

user_pword = promptUser_PWord.get_user_pword()

A+
Laurent
> 
> Many thanks for your attention to this matter.
> 
> KD

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

Re: DSLs in perl and python (Was sobering observation)

[Mark Lawrence]

On 17/03/2016 17:47, Rustom Mody wrote:

On Thursday, March 17, 2016 at 10:09:27 PM UTC+5:30, Charles T. Smith wrote:

or something else ... you're in a "defend python at all costs!" mode.

So now my questions:

How do you in perl make regexps readable like python's VERBOSE?
Can you do better in perl?



I neither know, nor do I care.  Why not ask on a perl list?

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: How to waste computer memory?

[Chris Angelico]

On Fri, Mar 18, 2016 at 10:46 PM, Steven D'Aprano  wrote:
> On Fri, 18 Mar 2016 06:00 pm, Ian Kelly wrote:
>
>> On Thu, Mar 17, 2016 at 1:21 PM, Rick Johnson
>>  wrote:
>>> In the event that i change my mind about Unicode, and/or for
>>> the sake of others, who may want to know, please provide a
>>> list of languages that *YOU* think handle Unicode better than
>>> Python, starting with the best first. Thanks.
>
> Better than Python? Easy-peasy:
>
> List of languages with Unicode handling which is better than Python = []
>
> I'm not aware of any language with better or more complete Unicode
> functionality than Python's. (That doesn't necessarily mean that they don't
> exist.)

And this also doesn't preclude languages that have *as good* handling
as Python's, of which I know of one off-hand, and there may be any
number. (Trivial case: Take Python 3.5, change the definition of a
block to be { } instead of indentation, and release it as Bracethon
1.0. Voila, a distinct-yet-related language whose Unicode handling is
exactly as good as Python's.)

>> jmf has been asked this before, and as I recall he seems to feel that
>> UTF-8 should be used for all purposes, ignoring the limitations of
>> that encoding such as that indexing becomes a O(n) operation.
>
> Technically, UTF-8 doesn't *necessarily* imply indexing is O(n). For
> instance, your UTF-8 string might consist of an array of bytes containing
> the string, plus an array of indexes to the start of each code point. For
> example, the string:
>
> “abcπßЊ•𒀁”
>
> (including the quote marks) is 10 code points in length and 22 bytes as
> UTF-8. Grouping the (hex) bytes for each code point, we have:
>
> e2809c 61 62 63 cf80 c39f d08a e280a2 f0928081 e2809d
>
> so we could get a O(1) UTF-8 string by recording the bytes (in hex) plus the
> indexes (in decimal) in which each code point starts:
>
> e2809c616263cf80c39fd08ae280a2f0928081e2809d
>
> 0 3 4 5 6 8 10 12 15 19
>
> but (assuming each index needs 2 bytes, which supports strings up to 65535
> characters in length), that's actually LESS memory efficient than UTF-32:
> 42 bytes versus 40.

A lot of strings will have no more than 255 non-ASCII characters in
them. (For example, all strings which no more than 255 total
characters.) You could store, instead of the indexes themselves, a
series of one-byte offsets:

e2809c616263cf80c39fd08ae280a2f0928081e2809d
0 2 2 2 2 3 4 5 7 10

Locating a byte based on its character position is still O(1); you
look up that position in the offset table, add that to your original
character position, and you have the byte location. For strings with
too many non-ASCII codepoints, you'd need some other representation,
but at that point, it might be worth just switching to UTF-32.

Of course, O(1) isn't the ultimate goal to the exclusion of all else.
For a simple sequential parser, indexing might be such a rare
operation that it's okay for it to be O(N), as you're never going to
index more than a few characters from a known position. Or if you're
trying to search a few gig of text, it's entirely possible that
transcoding into an indexable format is a complete waste of time, and
it's better to just work with a stream of bytes straight off the disk.
But for a general string type in a high level language, I'm normally
going to assume that indexing is fairly cheap.

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

Re: Case Statements

[Antoon Pardon]

Op 16-03-16 om 20:27 schreef Marko Rauhamaa:
> Antoon Pardon :
>
>> Look at decorators. They don't provide functionality we wouldn't have
>> without them. So we don't actually need them. Do you argue that
>> introducing them wasn't progress?
> I do.

Way to miss the point. Sure there will be people for which this particular
example doesn't work. The point is, that often enough progress in python
is not about introducing something new that is "actually needed" but about
making functionality that is already available more easily accessible.

I am sure you can find your own examples if you search for them.

-- 
Antoon.

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

Re: empty clause of for loops

[Steven D'Aprano]

On Wed, 16 Mar 2016 09:23 pm, Sven R. Kunze wrote:

> Hi,
> 
> a colleague of mine (I write this mail because I am on the list) has the
> following issue:
> 
> 
> for x in my_iterable:
>  # do
> empty:
>  # do something else
> 
> 
> What's the most Pythonic way of doing this?


Doing what? What is the code supposed to do? What's "empty" mean as a
keyword?

If you explain what your friends wants, then perhaps we can suggest
something. Otherwise we're just guessing. I can think of at least two
different meanings:

* run the "empty" block only if my_iterable is empty at the start of the
first loop;

* run the "empty" block if my_iterable becomes empty after the first loop.



-- 
Steven

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

Re: Replace weird error message?

[Joel Goldstick]

can you show the complete code?  It doesn't start with "{:02} I don't think

On Wed, Mar 16, 2016 at 2:34 PM, the.gerenuk--- via Python-list <
python-list@python.org> wrote:

> The following error message, makes it a bit hard to understand what went
> wrong
>
> >>> "{:02}".format("1")
> Traceback (most recent call last):
>   File "", line 1, in 
> ValueError: '=' alignment not allowed in string format specifier
>
> (this can happen easily if you read in text files and forget to convert)
>
> Do you think some better error message should be used?
>
> For example a hint that "0" does work for the given argument.
> --
> https://mail.python.org/mailman/listinfo/python-list
>



-- 
Joel Goldstick
http://joelgoldstick.com/ 
http://cc-baseballstats.info/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to waste computer memory?

[Marko Rauhamaa]

Steven D'Aprano :

> One thing that NTFS gets right is that all path names are guaranteed
> to be well-formed, valid Unicode. I believe that they are stored in
> UTF-16, and unlike the ext file systems used on Linux, they are not
> arbitrary bytes.

https://msdn.microsoft.com/en-us/library/windows/desktop/dd31774
8%28v=vs.85%29.aspx> states that NTFS filenames disallow '\', '/', '.',
'?', '*' as well as '¥'. Apparently the ban on the yen symbol isn't
enforced by the FS.

I haven't found a direct statement whether NTFS internally enforces the
soundness of UTF-16 or if it is simply doing UCS-2.

https://msdn.microsoft.com/en-us/library/windows/desktop/dd374069
%28v=vs.85%29.aspx>:

   Using the surrogate mechanism, UTF-16 can support all 1,114,112
   potential Unicode characters.

But Unicode doesn't contain 1,114,112 characters—the surrogates are
excluded from Unicode, and definitely cannot be encoded using
UTF-anything.

Furthermore, the page notes:

   Note Windows 2000 introduces support for basic input, output, and
   simple sorting of supplementary characters. However, not all system
   components are compatible with supplementary characters.

(Somewhat related, Python doesn't enforce the soundness of Unicode
because Python allows surrogate code points in strings.)

> I believe that HFS+ on Apple Macs goes one step further and guarantees
> that paths are always fully normalised, so that it's impossible to
> have (e.g.) two files ã (U+00E3 LATIN SMALL LETTER A WITH TILDE) and ã
> (U+0061 LATIN SMALL LETTER A + U+0303 COMBINING TILDE) in the same
> directory.
>
> Unfortunately, backwards compatibility is holding Linux file systems
> back...

Linux got lucky by not jumping the gun. We are still waiting for the
dust to settle.

Unicode made several (understandable but grave) mistakes along the way:

   * UCS-2

   * supplementary code points

   * BOM

   * endianness

   * normalization

We still don't know if the final result will be UCS-4 everywhere (with
all 2**32 code points allowed?!) or UTF-8 everywhere.


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

Re: empty clause of for loops

[Sven R. Kunze]

On 16.03.2016 14:09, Tim Chase wrote:

If you can len() on it, then the obvious way is

   if my_iterable:
 for x in my_iterable:
   do_something(x)
   else:
 something_else()

However, based on your follow-up that it's an exhaustible iterator
rather than something you can len(), I'd use enumerate:

   count = 0 # have to set a default since it doesn't get assigned
 # if no iteration happens
   for count, x in enumerate(my_iterable, 1):
 do_something(x)
   if not count:
 something_else()


Interesting variation. Good to keep in mind if I encounter a situation 
where I need both (empty flag + counter). Thanks. :)



I do a lot of ETL work, and my code often has to report how many
things were processed, so having that count is useful to me.
Otherwise, I'd use a flag:

   empty = True
   for x in my_iterable:
 empty = False
 do_something(x)
   if empty:
 something_else()


Best,
Sven
--
https://mail.python.org/mailman/listinfo/python-list

TSP in python ; this is code to solve tsp whenever called, where given coordinates as in name of pos and then start coordinate as in start, help me how it works ?

[Qurrat ul Ainy]

from os import system, getcwd, chdir

def tsp_generate_hops(pos, start, length):
   hops = []
   tour = solve_tsp(pos)
   c = -1
   for hop in tsp_hop_gen(tour, start):
  c += 1
  hops.append(hop)
  if c == length:
 break
   return hops

def solve_tsp(data):
   old_cwd = getcwd()
   chdir('/tmp')
   data_len = len(data)
   f = file('tmp.tsp', 'w')
   f.write('TYPE : TSP\nDIMENSION: %d\nEDGE_WEIGHT_TYPE : 
EUC_2D\nNODE_COORD_SECTION\n' % data_len)
   for i in range(0, len(data)):
  entry = data[i]
  f.write('%d %f %f\n' % (i + 1, entry[0], entry[1]))
   f.write('EOF\n')
   f.close()
   try:
  system('concorde tmp.tsp > /dev/null')
  tour = []
  for line in file('tmp.sol').readlines()[1:]:
 for value in line.strip().split(' '):
tour.append(int(value))
   except:
  raise RuntimeError('could not compute TSP')
   chdir(old_cwd)
   return tour

def tsp_hop_gen(tour, start):
   '''
   hop generator based on tsp solved tour,
   starting at the given start hop
   '''
   y = False
   for hop in tour:
  if hop == start:
 y = True
  if y:
 yield hop
   while True:
  for hop in tour:
 yield hop
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to waste computer memory?

[Mark Lawrence]

On 19/03/2016 04:05, Ian Kelly wrote:

On Fri, Mar 18, 2016 at 3:19 PM, Mark Lawrence  wrote:


I have no idea at what the above can mean, other than that you are agreeing
with the RUE.


Mark, are you aware that this is a rather classic ad hominem of guilt
by association? "I didn't pay any attention to your actual argument,
but you seem to be agreeing with X and X is an idiot, so you must be
wrong."



I couldn't actually care less.  It looked to my autistic head that he 
was in agreement with the RUE.


Of course none of these comments would be made if people simply hadn't 
originally swallowed the bait from the most well known troll on this 
list, but hey ho.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: How to waste computer memory?

[Marko Rauhamaa]

Chris Angelico :

> On Sat, Mar 19, 2016 at 7:22 PM, Marko Rauhamaa  wrote:
>> Not all files have pathnames. Those that do have numerous pathnames. You
>> can't tell by looking at a file what pathnames, if any, it might have.
>> You need an exhaustive, recursive search of the file system for the
>> reverse mapping.
>>
>> If you execute the commands:
>>
>>echo hello >hello
>>rm hello
>>
>> You don't know for sure if the file you removed was the file you created
>> on the previous line.
>
> Not all objects in Python have names bound to them. Those that do may
> have multiple. You can't tell, by looking at an object, what pathnames
> it has. You need an exhaustive, recursive search of all namespaces for
> the reverse mapping.
>
> If you execute the commands:
>
> hello = re.compile("[Hh][Ee][Ll][Ll][Oo]")
> hello.match(msg)
>
> you don't know for sure if the object you called a method on was the
> one you created on the previous line.
>
> So are object names not part of Python?

What are you talking about, Chris?

Point is, UNIX file systems don't provide for inode handles. You have
pathnames and file descriptors, but you'd need something between the
two. The omission plagues UNIX application programmers and is the cause
of numerous bugs -- even when the programmers are not aware of the
danger.

Objects in Python have trivial references: just assign the object to a
variable.


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

Re: How to waste computer memory?

[Chris Angelico]

On Sat, Mar 19, 2016 at 8:31 PM, Marko Rauhamaa  wrote:
> Unicode made several (understandable but grave) mistakes along the way:
>
>* normalization
>

Elaborate please? What's such a big mistake here?

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

E-commerce system in Python

[Arshpreet Singh]

I am looking for an E-commerce system in python to sell things things online, 
which can also be responsive for Android and IOS. 

A  quick Google search brought me  http://getsaleor.com/ it uses Django, Is 
there any available one using Flask or newly born asyncio based framework?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: creating multiple python Django projects in Windows environment

[Chris Angelico]

On Sat, Mar 19, 2016 at 6:04 AM, jogaserbia  wrote:
> Can someone please give me ideas on what I should read about (or pay someone 
> to do) that would enable me to create a basis on which multiple Python (web 
> and non-web) applications can be access by staff in a windows environment.
>

You basically have two choices:

1) Run the Python app on some central server, and have your staff
access it using something they already have (eg a web server)

2) Have them all install Python and run it locally.

Your call. :)

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

Re: retrieve key of only element in a dictionary (Python 3)

[Daniel Wilcox]

I think you're looking for something like popitem().

>>> d = {'asdf':1}
>>> d.popitem()[0]
'asdf'

Cheers


On Fri, Mar 18, 2016 at 2:33 PM, Fillmore 
wrote:

>
> I must be missing something simple, but...
>
> Python 3.4.0 (default, Apr 11 2014, 13:05:11)
> [GCC 4.8.2] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> d = dict()
> >>> d['squib'] = "007"
> >>> # I forget that 'squib' is my key to retrieve the only element in d
> ...
> >>> type(d.items())
> 
> >>> key = d.items()[0]
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: 'dict_items' object does not support indexing
> >>> key,_ = d.items()
> Traceback (most recent call last):
>   File "", line 1, in 
> ValueError: need more than 1 value to unpack
> >>> key,b = d.items()
> Traceback (most recent call last):
>   File "", line 1, in 
> ValueError: need more than 1 value to unpack
> >>> print(d.items())
> dict_items([('squib', '007')])
> >>> print(d.items()[0])
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: 'dict_items' object does not support indexing
> >>>
>
> what am I missing? I don't want to iterate over the dictionary.
> I know that there's only one element and I need to retrieve the key
>
> thanks
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: sobering observation, python vs. perl

[Charles T. Smith]

On Thu, 17 Mar 2016 09:21:51 -0700, Ethan Furman wrote:

>> well, I don't want to forgo REs in order to have python's numbers be 
>> better
> 
> The issue is not avoiding REs, but using Python's strengths and idioms. 
>   Write the code in Python's style, get the same results, then compare 
> the times.


Yes, your point was to forge REs despite that they are useful.
I could have thought the search would have been better as:

'release[-.:][Rr]eq'

or something else ... you're in a "defend python at all costs!" mode.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: empty clause of for loops

[Sven R. Kunze]

On 16.03.2016 14:58, alister wrote:
no , i just typed it, while trying to hold a conversation with swmbo 
:-( apologies to the op if e could not see where i was intending to go 
with this. 


No problem, I perform quite well at guessing folk's intention.

So, yes, I can extrapolate what you meant. Thanks. :)

Best,
Sven
--
https://mail.python.org/mailman/listinfo/python-list

Re: Beginner Python Help

[Chris Warrick]

On 18 Mar 2016 08:05, "Alan Gabriel"  wrote:
>
> Hey there,
>
> I just started out python and I was doing a activity where im trying to
find the max and min of a list of numbers i inputted.
>
> This is my code..
>
> num=input("Enter list of numbers")
> list1=(num.split())
>
> maxim= (max(list1))
> minim= (min(list1))
>
> print(minim, maxim)
>
>
>
> So the problem is that when I enter numbers with an uneven amount of
digits (e.g. I enter 400 20 36 85 100) I do not get 400 as the maximum nor
20 as the minimum. What have I done wrong in the code?

You're dealing with strings (text) and not integers. And when comparing
strings, '1' is earlier than '2', thus '100' < '20'.

To fix this, you can use a list comprehension:

list1 = [int(i) for i in num]

You also don't need (parentheses) around functions when assigning to
variables:

maxim = max(list1)
minim = min(list1)

(Also, list1 is not a good variable name. Try something that describes its
contents.)

-- 
Chris Warrick 
Sent from my Galaxy S3.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Bash-like pipes in Python

[Random832]

On Wed, Mar 16, 2016, at 11:09, Joel Goldstick wrote:
> > This is interesting, but the part I'm missing is the use of the Pipe
> symbol '|' in python.  Can you elaborate

His "Filter", "Map", and "Reduce" are classes which define __ror__
methods, obviously.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: from a module return a class

[kevind0718]

On Friday, March 18, 2016 at 12:16:13 PM UTC-4, John Gordon wrote:
> In  Wolfgang Maier 
>  writes:
> 
> > > So promptUser_PWord is a module?  Well, I'm confused.  You gave us this
> > > bit of code:
> > >
> > >  user_pword = promptUser_PWord()
> > >
> > > But that can't work if promptUser_PWord is a module; modules aren't
> > > callable.  promptUser_PWord() has to be a function or a class.
> > >
> 
> > Yes, but I guess the OP's program will run into the SyntaxError when 
> > trying to import the module, i.e., before it ever encounters the 
> > TypeError: 'module' object is not callable.
> 
> Good point; I hadn't thought of that.
> 
> -- 
> John Gordon   A is for Amy, who fell down the stairs
> gor...@panix.com  B is for Basil, assaulted by bears
> -- Edward Gorey, "The Gashlycrumb Tinies"

true I get the following:  
  File "H:\dev\eclipse\workspace\genXls\src\genXls\genXlswPrompt.py", line 11, 
in 
import promptUser_PWord
  File "H:\dev\eclipse\workspace\genXls\src\genXls\promptUser_PWord.py", line 58
return user_pword
SyntaxError: 'return' outside function

so what I get from the various postings is promptUser_PWord must be
converted to a class.  True?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to waste computer memory?

[Chris Angelico]

On Sat, Mar 19, 2016 at 8:02 AM, Marko Rauhamaa  wrote:
> Chris Angelico :
>> On Sat, Mar 19, 2016 at 2:26 AM, Marko Rauhamaa  wrote:
>>> It may be that Python's Unicode abstraction is an untenable illusion
>>> because the underlying reality is 8-bit and there's no way to hide it
>>> completely.
>>
>> The underlying reality is 1-bit. Or maybe the underlying reality is
>> actually electrical signals that don't even have a clear definition of
>> "bits" and bounce between two states for a few fractions of a second
>> before settling. And maybe someone's implementing Python on the George
>> Banks Kite CPU, which consists of two cents' worth of paper and
>> string, on which text is actually represented by glyph. They're all
>> equally valid notions of "underlying reality".
>>
>> Text is an abstract concept, just as numbers are.
>
> The question is how tenable the illusion is. If the OS gave the
> appropriate guarantees (say, all pathnames are encoded Unicode strings),
> the abstraction could be maintained. Unfortunately, the legacy shines
> through making you wonder if Python has overreached prematurely with its
> Unicode HAL.

The problem is not Python's Unicode strings, then. The problem is the
notion that path names are text. If they're text, they should be
exclusively text (although, for low-level efficiency, they're more
likely to be defined as "valid UTF-8 sequences" rather than "sequences
of Unicode codepoints"); since they're not, they are fundamentally
bytes. But that's not a problem with Python - it's a problem with the
file system.

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

Re: Need explanation of this error

[Bryan Bateman]

Having the same error with python 3.5 windows 64 bit and scipy for same on
Windows 10.  I did dependency walker and it came up with a large number of
DLL's.  Do you want the source of the scipy binary and the DLL list?

 

https://mail.python.org/pipermail/python-list/2013-July/651190.html

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

Re: How to waste computer memory?

[Marko Rauhamaa]

Chris Angelico :

> On Sat, Mar 19, 2016 at 8:31 PM, Marko Rauhamaa  wrote:
>> Unicode made several (understandable but grave) mistakes along the way:
>>
>>* normalization
>
> Elaborate please? What's such a big mistake here?

Unicode shouldn't have allowed multiple equivalent variants for a
string.

Now Python falls victim to:

   >>> '\u006e\u0303' == '\u00f1'
   False

https://en.wikipedia.org/wiki/Unicode_equivalence>:

   For example, the code point U+006E (the Latin lowercase "n") followed
   by U+0303 (the combining tilde "◌̃") is defined by Unicode to be
   canonically equivalent to the single code point U+00F1 (the lowercase
   letter "ñ" of the Spanish alphabet). Therefore, those sequences
   should be displayed in the same manner, should be treated in the same
   way by applications such as alphabetizing names or searching, and may
   be substituted for each other.


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

About PyPi: ETA from publish to searchable?

[Daniel Wilcox]

Hello!

I just recently published my first package to PyPi and was wondering -- how
long will it take before I actually can see it if I'm searching for it?  I
imagine the indexes are on some schedule but I'm chomping at the bit --
about how long is that?

Thanks,
-D

https://pypi.python.org/pypi/vcardtools/

ps:  If you're interested in using CardDAV to host your own contacts and
calendars,  or like command line/curses mail readers... the package may
even be helpful for you.  I know you mailhandler[1] fans are still out
there -- mh for life j/k. ;-)

[1] https://engineering.purdue.edu/ECN/Support/KB/Docs/MailHandlerMHUsingMH
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: WP-A: A New URL Shortener

[Thomas 'PointedEars' Lahn]

Rick Johnson wrote:

> On Thursday, March 17, 2016 at 1:28:05 PM UTC-5, Thomas 'PointedEars' Lahn
> wrote:
> 
>> BTW and JFTR, this thread has gone *way* off topic.
    
> Who cares? Python-list is not a "strictly moderated group". [rant]

Get a life, *please*.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to waste computer memory?

[Random832]

On Fri, Mar 18, 2016, at 10:59, Michael Torrie wrote:
> This seems to me to be a leaky abstraction.  Julia's approach is
> interesting, but it strikes me as somewhat broken as it pretends to do
> O(1) indexing, but in reality it's still O(n) because you still have to
> iterate through the bytes until you find, say, the nth time that doesn't
> raise an exception.  Except for dealing with the ASCII subset of UTF-8,
> I can't really see any time when grabbing whatever resides at the nth
> byte of a UTF-8 string would be useful.

Well, that depends on what "n" is. If it's the value returned by a
search of the same string, then it's useful. So long as, naturally, your
search function returns a byte index.

And, for that matter, you're going to have to explain when grabbing
whatever resides at the nth *character* is useful.

> I guess whether or not you need to find the nth character depends on the
> strength of string functions.  If I searched a string for a particular
> delimiter, I could see it being useful to get whatever is just past the
> delimiter, for example.

Well, you know the length of the delimiter, don't you? Instead of adding
one (who says the delimiter has to be one code point, either?), just add
that.

delim = ","
dlen = len(delim) # length in bytes
result = foo[foo.indexof(delim)+dlen:] # index in bytes, slice by bytes

> Though Python's split() method eliminates the
> need to do that by hand.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Beautifulsoap

[Peter Otten]

epro...@gmail.com wrote:

> 
> Yes, for my hobby i want extract odds.
> 
> The code is:
> 
> from bs4 import BeautifulSoup
> 
> import urllib2
> 
> url =
> "http://www.betexplorer.com/soccer/england/premier-league-2014-2015/results/";
> 
> content = urllib2.urlopen(url).read()
> 
> soup = BeautifulSoup(content)
> 
> odds = soup.find_all("td", class_="odds")
> for odd in odds:
>   print odd
> 
> And I have this list of object:
> 
> ...
> 
> 
> 
> 
> From this object I'm interesting only 3.70 3.65 3.48 etc
> 
> I'm no a programmer, my hobby is analyze soccer matchs to try to win :-)
> I chose python because I think is the best :-)
> 
> Thank you in advance

The interactive interpreter is a good tool to try to access various elements 
in the "soup":

$ python -i yourcode.py # enter the interpreter when your script terminates
[snip] 


>>> 
>>> odd

>>> odd.attrs["data-odd"]
'2.04'

If you want to do calculations you have to convert the string to a number 
first:

>>> float(odd.attrs["data-odd"])
2.04

You probably want the match, too, so it may be better to go for the  
elements in the first table:

>>> for tr in soup.table.find_all("tr", class_="strong"):   
>>>   
... print tr.find(class_="first-cell").string,
... print float(tr.find(class_="odds").attrs["data-odd"]) 
... 
Aston Villa - Burnley 2.2
Crystal Palace - Swansea 1.81
Hull City - Manchester United 3.1
[snip]


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

Re: Bash-like pipes in Python

[Steven D'Aprano]

On Thu, 17 Mar 2016 02:20 am, Random832 wrote:

> How about:
> 
> from functools import partial, reduce
> from operator import mul
> def rcall(arg, func): return func(arg)
> def fpipe(*args): return reduce(rcall, args)
> pfilter = partial(partial, filter)
> pmap = partial(partial, map)
> preduce = partial(partial, reduce)
> 
> fpipe("abcd12345xyz", pfilter(str.isdigit), pmap(int), preduce(mul))

Intriguing! Thank you for the suggestion.


-- 
Steven

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

Re: Case Statements

[Marko Rauhamaa]

BartC :

> On 16/03/2016 14:31, Marko Rauhamaa wrote:
>> Scheme has this:
>
>> (case (die10)
>>   ((1 3 5 7 9)
>>=> (lambda (n)
>> n))
>>   (else
>>=> (lambda (n)
>> (/ n 2
>>
>> which maps 1, 3, 5, 7 and 9 onto themselves but halves 2, 4, 6, 8 and
>> 10.
>
> I don't get this; what does the lambda do here? Why not just yield
> either n or n/2?

Scheme is all about lambdas. They are everywhere. The margin of this
posting is too small for me to explain it.

>> As for a chained if/elif, Scheme as "cond:"
>
>> (cond
>>  ((windy?)
>>   (fly-kite))
>>  ((shining? sun)
>>   (go-out))
>>  ((raining?)
>>   (play-soccer))
>>  (else
>>   (read-book)))
>
> Which is like my Ruby case example. Simple and to the point. (Not sure
> of the significance of ?)

Scheme identifiers can contain punctuation characters. Functions that
return a boolean are conventionally given names that end in a question
mark. Functions that modify their arguments are conventionally given
names that end in an exclamation point.


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

Re: sobering observation, python vs. perl

[Marko Rauhamaa]

"Charles T. Smith" :

> On Thu, 17 Mar 2016 17:48:54 +0200, Marko Rauhamaa wrote:
>> Try running the sed command again after setting:
>> 
>> export LANG=C
>
> Hmmm.  Interesting thought.  But...
>
> $ locale
> LANG=C

Ok. The LANG=C setting has a tremendous effect on the performance of
textutils.


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

Re: How to waste computer memory?

[alister]

On Fri, 18 Mar 2016 07:42:30 +1100, Chris Angelico wrote:

> On Fri, Mar 18, 2016 at 7:31 AM,   wrote:
>> Rick Johnson  wrote:
>>>
>>> In the event that i change my mind about Unicode, and/or for the sake
>>> of others, who may want to know, please provide a list of languages
>>> that *YOU* think handle Unicode better than Python, starting with the
>>> best first. Thanks.
>>>
>> How about a list of languages that Unicode handles better than ASCII?
>> Like almost every language *except* English.
> 
> Like every language *including* English. You can pretend that ASCII is
> enough, but you do lose some information.
> 
> ChrisA

as we all seam to have bitten the troll's thread
"how to waste computer memory"
give it to an delusion-ed incompetent to play with

it is now 2016 not 1978, Memory is cheap. plentifully and fast there is 
more than enough to go arround



-- 
May your camel be as swift as the wind.
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Replace weird error message?

[Dan Strohl via Python-list]

Actually, I think that was the complete code... give it a try...

"{:02}".format("1")

produces the error listed.

I agree the error is not very clear, since the "=" was not passed, it seems 
like an incorrect error.  What about something like:

"ValueError: '=' and '0' padding are not allowed in string format specifiers"

> -Original Message-
> From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org]
> On Behalf Of Joel Goldstick
> Sent: Wednesday, March 16, 2016 11:39 AM
> Cc: python-list@python.org
> Subject: Re: Replace weird error message?
> 
> can you show the complete code?  It doesn't start with "{:02} I don't think
> 
> On Wed, Mar 16, 2016 at 2:34 PM, the.gerenuk--- via Python-list < python-
> l...@python.org> wrote:
> 
> > The following error message, makes it a bit hard to understand what
> > went wrong
> >
> > >>> "{:02}".format("1")
> > Traceback (most recent call last):
> >   File "", line 1, in 
> > ValueError: '=' alignment not allowed in string format specifier
> >
> > (this can happen easily if you read in text files and forget to
> > convert)
> >
> > Do you think some better error message should be used?
> >
> > For example a hint that "0" does work for the given argument.
> > --
> > https://mail.python.org/mailman/listinfo/python-list
> >
> 
> 
> 
> --
> Joel Goldstick
> http://joelgoldstick.com/ 
> http://cc-baseballstats.info/
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Obfuscating Python code

[Daniel Wilcox]

If you really want to learn about obfuscating python bytecode so it can't
be reverse engineered (easily) -- there are people who are doing it.
Search for 'pyasm' on github as a starting point.  tldr; yes people are
patching .pyc files. yes you can make them a nightmare to disassemble. and
yes it slows down your code.

=D

also yes, you can be tricked into running a patched .pyc file that has
nothing to do with your .py file, you have been warned.  be careful out
there.

On Tue, Mar 15, 2016 at 2:51 PM, Thomas 'PointedEars' Lahn <
pointede...@web.de> wrote:

> Chris Angelico wrote:
>
> > On Wed, Mar 16, 2016 at 5:59 AM, Thomas 'PointedEars' Lahn
> >  wrote:
> >> That said, not distributing the source code of a program as well (or at
> >> least making it available to users in some way) strikes me as unpythonic
> >> since Python is at least Open Source software, and Python 2.0.1, 2.1.1
> >> and newer are GPL-compatible Free Software.
> >
> > gcc is also free software. Does that mean that all C programs should
> > be free software? No.
>
> IMNSHO, yes.  At the very least because in using gcc you benefited from the
> free software community, so you should give back to the free software
> community accordingly.
>
> > However, since all software can be reverse-compiled (particularly
>
> You mean _decompiled_.
>
> > byte-code like .pyc files),
>
> Yes, it is easier with bytecode *if you know the VM*.
>
> > the only truly reliable way to make completely closed software is to
> > restrict access to it in all forms.
>
> ACK.
>
> > In today's world, that usually means providing it as a web service.
>
> ACK.  That’s why RMS calls it SaaSS, Service as a Software Substitute :)
>
> > Otherwise, you have to assume that anyone can see your source. The
> > only difference between open-source and closed-source is the license,
> > not the ability to see stuff.
>
> If that were the case and reverse engineering were an easy task that
> everyone could do, we would have a lot more free software variants of
> proprietary software.  Particularly, we would have a lot less proprietary
> device drivers.  ISTM that you do not know what you are talking about here.
>
> --
> PointedEars
>
> Twitter: @PointedEars2
> Please do not cc me. / Bitte keine Kopien per E-Mail.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to waste computer memory?

[Chris Angelico]

On Fri, Mar 18, 2016 at 7:31 AM,   wrote:
> Rick Johnson  wrote:
>>
>> In the event that i change my mind about Unicode, and/or for
>> the sake of others, who may want to know, please provide a
>> list of languages that *YOU* think handle Unicode better than
>> Python, starting with the best first. Thanks.
>>
> How about a list of languages that Unicode handles better than ASCII?
> Like almost every language *except* English.

Like every language *including* English. You can pretend that ASCII is
enough, but you do lose some information.

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

Re: How to waste computer memory?

[Steven D'Aprano]

On Sat, 19 Mar 2016 09:18 pm, Chris Angelico wrote:

> On Sat, Mar 19, 2016 at 8:31 PM, Marko Rauhamaa  wrote:
>> Unicode made several (understandable but grave) mistakes along the way:
>>
>>* normalization
>>
> 
> Elaborate please? What's such a big mistake here?

As usual, Unicode problems are generally due to backwards compatibility.
Blame the old legacy encodings, which invented the "dead keys"
a.k.a. "combining character" technique. Of course, they had a reasonable
excuse at the time, but Unicode's requirement of being able to losslessly
handle all legacy character set standards means that Unicode has to provide
the same functionality.

The problem is not so much the existence of combining characters, but that
*some* but not all accented characters are available in two forms: a
composed single code point, and a decomposed pair of code points. This adds
complexity and means that equality of characters is not well-defined.
(Hence Unicode punts on the whole "character" thing and just talks about
code points.)



-- 
Steven

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