Re: Is it bad practise to write __all__ like that

[mark ferguson]

Thomas,

A ha! Now I feel all warm and fuzzy inside. It's nice to start the day with
learning something new.

To be honest, the initial problem was that I didn't understand the meaning
of '__all__', again probably from not working in the large with python.
After posting, I went and had another go at understanding decorators. I
think your second decorator example is the neatest one I have seen and it is
quite obvious where the value of the decorator here is. You have used a
minimal amount of code to solve a potentially major long term code
maintenance problem. I will echo Karim here, a very elegant solution.

On 29 July 2011 07:37, Thomas Rachel <
nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa...@spamschutz.glglgl.de> wrote:

> Am 28.07.2011 20:01 schrieb Ian Kelly:
>
>
>  The advantage of Thomas's decorator here is that it lets you place the
>> denotation of whether a function is exported alongside its definition,
>> whereas simply declaring the __all__ list forces you to separate them.
>>  It also avoids the problem of possibly mistyping the function's name
>> in the list.
>>
>
> Thank you. For the ones who do not like @__all__ because it might look
> ugly, here is an alternative:
>
> __all__ = []
>
> def export(obj):
>__all__.append(obj.__name__)
>return obj
>
> It is nearly the same, but without an extra class and with the more
> readable
>
> @export
> def func(): pass
>
>
> Thomas
>
> --
> http://mail.python.org/**mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: gettext switch language on the fly

[Peter Irbizon]

hello Chris,

I am using pygtk.

2011/7/29 Chris Rebert 

> On Thu, Jul 28, 2011 at 6:20 PM, Peter Irbizon 
> wrote:
> > hello,
> > I am using gettext fo localization
> 
> > Now I would like to switch all texts in my app when I click on item in
> menu.
> > Unfortunatelly this not switch texts immediately. How can I do this?
>
> Which GUI toolkit are you using?
>
> Cheers,
> Chris
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: multilanguage application - step by step

[Peter Irbizon]

Hello Thomas,

> The usual way of using gettext is to use the system locale to determine
> the right language. Of course, you can have different translations and
> install() them (I expect), but you'll have to re-load all the strings
> displayed in your application when you switch language, which might be
> tricky.
thank you now it works and all my string are translated. But as you said
switching languages is small problem now. I am using pygtk and I have no
idea how to re-load all strings in my app when I click on button with
another language. Any idea?

> The usual way of using gettext is to use the system locale to determine
Why is usually gettext use with system locale? I think the better way is to
leave user to select his language (or switch to another). Should I use
something else than gettext in this case? thanks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: shlex parsing

[Karim]

On 07/29/2011 09:24 AM, Web Dreamer wrote:

Nobody a écrit ce jeudi 28 juillet 2011 18:37 dans
  :


On Thu, 28 Jul 2011 17:48:34 +0200, Web Dreamer wrote:


I would like to parse this TCL command line with shlex:

'-option1 [get_rule A1 B2] -option2 $VAR -option3 TAG'

s = s.replace('[','"[')
s = s.replace(']',']"')

Note that this approach won't work if you have nested brackets or braces.
That would require a real parser.

True,
I tried with the shlex class, but adding '[]' to a shlexobject.quotes
doesn't work.
Indeed, shlex expects an opening and closing quote to be the same, and [ is
different from ] so shlex therefore expects an opening [ to be closed with [
and not ]

My solution indeed only works as long as there are not any nested brackets.

Yeah I saw that shlex object behavior is slighty different from 
shlex.split()
fonction. the char minus by default is taken as a individual word and in 
split
it is not. get_token() method return '-' alone and you have to set 
object attributes

wordchars += '-' to have the same behavior as shlex.split().

Cheers
Karim

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

Re: multilanguage application - step by step

[Thomas Jollans]

On 29/07/11 11:18, Peter Irbizon wrote:
> Hello Thomas,
>  
> > The usual way of using gettext is to use the system locale to determine
> > the right language. Of course, you can have different translations and
> > install() them (I expect), but you'll have to re-load all the strings
> > displayed in your application when you switch language, which might be
> > tricky.

> thank you now it works and all my string are translated. But as you
> said switching languages is small problem now. I am using pygtk and I
> have no idea how to re-load all strings in my app when I click on
> button with another language. Any idea?
>  
>

Well, it depends on how you're constructing your interface. If you're
creating all the widgets in Python code, you could move all your
foo.text = "Bar"; statements to one method that updates the text for all
widgets, and call that both from the constructor and from the
language-switching event handler.

If you're using Glade, your only option might be to completely reload
the interface, but then you'd somehow have to save the user's data and
immediately restore it perfectly.

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

how to make checkitem menu and allow to be checked only one item?

[Peter Irbizon]

Hello geeks, I have this code in my app:
self.menu_items = (
( "/_Languages", None,None, 0, "" ),
( "/Languages/_english", None,self.print_lang, 0, ""
),
( "/Languages/_german",  None,self.print_lang, 0, ""
),
)

self.vbox = gtk.VBox(False, 0)
self.menubar = self.get_main_menu(self.okno)
self.vbox.pack_start(self.menubar, False, True, 0)
self.menubar.show()

def get_main_menu(self, window):
accel_group = gtk.AccelGroup()
item_factory = gtk.ItemFactory(gtk.MenuBar, "", accel_group)
  # This method generates the menu items. Pass to the item factory
  #  the list of menu items
item_factory.create_items(self.menu_items)
  # Attach the new accelerator group to the window.
window.add_accel_group(accel_group)
  # need to keep a reference to item_factory to prevent its
destruction
self.item_factory = item_factory
  # Finally, return the actual menu bar created by the item factory.
return item_factory.get_widget("")

how to make checkitem menu and allow to be checked only one item? I would
like to have english checked but not german at the same time. And when I
click on german it should uncheck english. How to make this?

And other question: I am using self.print_lang function and I would like to
have something like this ( "/Languages/_english",
None,self.print_lang('en'), 0, "" )
but the problem is self.print_lang('en') with parameter 'en' is
automatically executed after app run. I can use only self.print_lang without
parameter or use callback integer (default-0, or other integers) - but this
is not very comfortable. Any advice for this?

many thanks in advance
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is it bad practise to write __all__ like that

[Karim]

On 07/29/2011 08:37 AM, Thomas Rachel wrote:

Am 28.07.2011 20:01 schrieb Ian Kelly:


The advantage of Thomas's decorator here is that it lets you place the
denotation of whether a function is exported alongside its definition,
whereas simply declaring the __all__ list forces you to separate them.
  It also avoids the problem of possibly mistyping the function's name
in the list.


Thank you. For the ones who do not like @__all__ because it might look 
ugly, here is an alternative:


__all__ = []

def export(obj):
__all__.append(obj.__name__)
return obj

It is nearly the same, but without an extra class and with the more 
readable


@export
def func(): pass


Thomas


I did not plan that this topic introduce so many great ideas.
It started from a simple question and ended up with new
and beautiful solution.
Very pleased of the collective spirit of this mailing list.
It changed from non-sense verbal fightings I saw earlier in some discussions
like perl versus python related topic.

Karim

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

Re: multilanguage application - step by step

[Peter Irbizon]

> Well, it depends on how you're constructing your interface. If you're
> creating all the widgets in Python code, you could move all your
> foo.text = "Bar"; statements to one method that updates the text for all
> widgets, and call that both from the constructor and from the
> language-switching event handler.

Thanks again. I am using pygtk so I should call function to change all text,
labels, etc. (I thought there is simplier solution) But I don't know how to
change texts on menu items. Usually I am using this code to build menus: Any
advice how to refresh menus please?
   self.menu_items = (
( "/_Languages", None,None, 0, "" ),
( "/Languages/_english", None,self.print_lang, 0, ""
),
( "/Languages/_german",  None,self.print_lang, 0, ""
),
)

self.vbox = gtk.VBox(False, 0)
self.menubar = self.get_main_menu(self.okno)
self.vbox.pack_start(self.menubar, False, True, 0)
self.menubar.show()

def get_main_menu(self, window):
accel_group = gtk.AccelGroup()
item_factory = gtk.ItemFactory(gtk.MenuBar, "", accel_group)
item_factory.create_items(self.menu_items)
window.add_accel_group(accel_group)
self.item_factory = item_factory
return item_factory.get_widget("")
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 8 and extraneous whitespace

[Chris Angelico]

On Thu, Jul 28, 2011 at 4:18 PM, OKB (not okblacke)
 wrote:
> Thomas 'PointedEars' Lahn wrote:
>>  Automatic word-wrap, where available, really is not a solution; it
>> is a bad workaround to a problem caused by the original author of
>> the source code that can be easily avoided by them taking more care
>> while coding.
>
>        I think exactly the opposite.  The source file should reflect the
> semantic organization of the code, without extraneous concessions to
> visual display (like "lining things up" with spaces or splitting long
> lines with hard newlines).  The editor should present the code nicely.
> People already argue for this general mindset when they say that "any
> good edit will let you set the tab width", etc.

That mandates that formatting NOT be a part of the language. I could
take C code and reformat it in various ways with a script, and easily
guarantee that the script won't affect the code by simply having it
only ever adjust whitespace. This concept simply won't work in Python.

Personally, I like to be able to format things according to where they
came from, or other criteria. Take a look at this code, for instance;
the post has highlighted the difference between 1 and 0, but otherwise
hasn't changed it:

http://thedailywtf.com/Articles/The-Shapes.aspx

Note how the formatting is beautifully consistent. Each line is
wrapped to a tidy 70 characters, or whatever it is (I haven't
counted). Each data row, therefore, has the same number of characters
in it. But is that useful? Would it not be far more useful to wrap
them each at their image widths? Yes, it might take a bit more
vertical space, but the source code would *look like the image* and
that massively helps readability. This is why a source code tidying
script can't fully grok readability; if a program looks at a sequence
of strings, how can it know where to break them? All of these
(hypothetical) examples are single string literals, broken across
lines:

-
"This is string 1.\0"
"This is string 2, and it is longer.\0"
"String 3.\0"
-
"This is a long paragraph of"
"text, which I have wrapped somewhat messily, and"
"which a good text"
"tidying program should be able to clean up"
"for me."
-
"Usage: programname [options] [argument]\n"
"-f\tFooify\n"
"-b\tBarify\n"
"\n"
"argument should be either '5-minute' or 'course'\n"
-

Can you write a script that perfectly handles these sorts of literals?
Considering that the divider in the first one might not be \0, but
might be any character or even string of characters, it's not really
possible for an editor to know where to wrap something; which means
that it's up to the programmer to make things readable. And that
demands that the programmer know what he's doing, and that the
programmer have the power to express what he's doing how he chooses.
Overly-strict formatting rules/guides remove that power.

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

change gtk STOCK_SAVE label text on the fly

[Peter Irbizon]

Hello,

how could I change STOCK_SAVE label text? I would like to have "Save it!"
instead of "Save"
And other question related to this is how can I change translation of
STOCK_SAVE on the fly? I think I need to set locale for pygtk...but don't
know how
-- 
http://mail.python.org/mailman/listinfo/python-list

Another win for profiling.

[Roy Smith]

It's often said that you shouldn't try to guess what's slow, but use 
profiling tools to measure what's slow.  I had a great example of that 
yesterday.  We have some web server code that does a big database 
(MongoDB) query and some post-processing of the data in python.  It 
worked fine in testing, but in production we started seeing slowness.

We had one query which was taking about 15 seconds to return 8000 
values.  We looked at the post-processing code and convinced ourselves 
everything was O(n log n) or better.  We looked at the database and 
convinced ourselves that all the required indexes existed.

So, I pulled out cProfile.  It turned out that fully 50% of the time was 
being spent in the gettz() calls in this routine:

def to_timestamp(d):
"""Convert d into a unix timestamp. d is assumed to be in UTC, as
the pymongo module returns datetimes based in UTC, but without
actual timezone information attached."""

d = d.replace(tzinfo = dateutil.tz.gettz('UTC'))
d = d.astimezone(dateutil.tz.gettz())
return time.mktime(d.timetuple()) + (d.microsecond / 1e6)

which was being called once per returned value from the database.  
Factoring out the gettz() calls got us a 2x speedup in page load time.  
Never would have found that without profiling.

Profiling also showed that most of the rest of the time was spent in the 
BSON deserialization routines.  We found a way to reduce the amount of 
data being returned, and eliminated most of that too.  If we stared at 
the code long enough we probably would have realized that on our own, 
but we never would have guessed the gettz() calls were so expensive.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: monotonically increasing memory usage

[Ulrich Eckhardt]

Pedro Larroy wrote:
> Just crossposting this from stackoverflow:
> 
> http://stackoverflow.com/...
> 
> Any hints?

At first I was just too lazy to visit stackoverflow and skipped this 
posting. Then I thought: Why didn't you include the content, so people can 
actually answer this question here? Therefore the only answer you got here 
is utterly useless because the whole context is missing!

Then, something worse dawned upon me: Since stackoverflow is a "free" site, 
their business model probably involves data mining or advertising, and since 
you just posted a link to that site with the sole goal of getting people to 
visit it, you have effectively (But I'm definitely not saying intentionally 
and knowingly!) become a spammer.

I'm really not blaming you, but this is puzzling me and I'm not sure how to 
react at the moment...

Cheers!

Uli

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

Re: list comprehension to do os.path.split_all ?

[Neil Cerutti]

On 2011-07-29, Dennis Lee Bieber  wrote:
> On Thu, 28 Jul 2011 15:31:43 -0600, Ian Kelly
>  declaimed the following in
> gmane.comp.python.general:
>
>> Using os.sep doesn't make it cross-platform. On Windows:
>> 
>> >>> os.path.split(r'C:\windows')
>> ('C:\\', 'windows')
>> >>> os.path.split(r'C:/windows')
>> ('C:/', 'windows')
>> >>> r'C:\windows'.split(os.sep)
>> ['C:', 'windows']
>> >>> r'C:/windows'.split(os.sep)
>> ['C:/windows']
>
>   Fine... So normpath it first...
>
 os.path.normpath(r'C:/windows').split(os.sep)
> ['C:', 'windows']
 

Here's a solution adapted from an initially recursive attempt.
The tests are currently somewhat gnarled to avoid displaying
os.path.sep. A simpler solution probably reimplement os.path.split,
an inconvenient implementation detail.

import os

def split_path(path):
"""Split path into a series of directory names, and return it
as a list.

If path is absolute, the first element in the list will be be
os.path.sep.

>>> p = split_path('/smith/jones')
>>> p[0] == os.path.sep
True
>>> p[1:]
['smith', 'jones']

>>> split_path('smith/jones')
['smith', 'jones']

>>> split_path('')
[]

>>> p = split_path('/')
>>> p[0] == os.path.sep
True
>>> len(p)
1
"""
head, tail = os.path.split(path)
retval = []
while tail != '':
retval.append(tail)
head, tail = os.path.split(head)
else:
if os.path.isabs(path):
retval.append(os.path.sep)
return list(reversed(retval))

if __name__ == '__main__':
import doctest
doctest.testmod()

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

Re: Only Bytecode, No .py Files

[John Roth]

On Jul 27, 8:56 am, Thomas Rachel  wrote:
> Am 27.07.2011 14:18 schrieb John Roth:
>
> > Two comments. First, your trace isn't showing attempts to open .py
> > files, it's showing attempts to open the Curses library in the bash
> > directory.
>
> Of course. My goal was to show that the OP's "problem" is not a python
> one, but occurs all over several programs.
>
>  > Maybe you also have a problem with the .py files,
>
> Why should I?
>
>  > It's also not showing the program that's causing the failing open.
>
> It is irrelevant, IMO.
>
> It just shows that it seems to be common, even for the bin loader, to
> search for libraries to be linked to by trying to open them from several
> places. So every program call must be full of "failures" shown by the
> "audit program".
>
> > Second, the audit program is an idiot. There are lots of programs
> > which use the "easier to ask forgiveness" pattern and test for the
> > existence of optional files by trying to open them. This may be what
> > Bash is doing.
>
> ACK. That is exactly what I wanted to show. (With the difference that
> this is probably nt the bash, but the linux loader trying to link a .so,
> but for the problem, it doesn't make any difference.)
>
> Thomas

Sorry. I thought what you posted was from the OP. I guess I don't
really expect someone to post a completely irrelevant trace in a
thread started by someone who has a problem.

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

Re: Only Bytecode, No .py Files

[Ethan Furman]

John Roth wrote:

ACK. That is exactly what I wanted to show. (With the difference that
this is probably nt the bash, but the linux loader trying to link a .so,
but for the problem, it doesn't make any difference.)


Sorry. I thought what you posted was from the OP. I guess I don't
really expect someone to post a completely irrelevant trace in a
thread started by someone who has a problem.


The trace was showing the same results in an effort to demonstrate that 
the "problem" was just normal operations.  This is very relevant.


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

Re: list comprehension to do os.path.split_all ?

[TheSaint]

Alan Meyer wrote:

> This is not properly portable to all OS, but you could simply split on
> the slash character, e.g.,
> 
> pathname.split('/')

more portable  pathname.split(os.sep)

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

Re: shlex parsing

[Karim]

On 07/29/2011 03:42 PM, Web Dreamer wrote:

whitespace_split = True

Thanks for the tip!

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

Re: Only Bytecode, No .py Files

[Jerry Hill]

On Fri, Jul 29, 2011 at 8:51 AM, John Roth  wrote:
> Sorry. I thought what you posted was from the OP. I guess I don't
> really expect someone to post a completely irrelevant trace in a
> thread started by someone who has a problem.

I'm not sure why you would think that that post was by the original
poster, or that it was irrelevant.  It seems to me that it
demonstrated exactly the behavior Eldon was complaining about as a
normal part of the operation of lots of normal unix programs.  Thomas
even said that in the very first line of his post (after the quoted
bit).

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

Re: Only Bytecode, No .py Files

[Thomas Rachel]

Am 29.07.2011 14:51 schrieb John Roth:


Sorry. I thought what you posted was from the OP. I guess I don't
really expect someone to post a completely irrelevant trace in a
thread started by someone who has a problem.


In what way do you find the trace irrelevant? It clearly shows that it 
is not a good idea for an "audit tool" to report all failing open() 
calls and that the OP's "problem" is none, at least not one related to 
Python.


No more, no less.


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

Re: Only Bytecode, No .py Files

[Alan Meyer]

On 07/26/2011 11:19 AM, Eldon Ziegler wrote:

Is there a way to have the Python processor look only for bytecode
files, not .py files? We are seeing huge numbers of Linux audit messages
on production system on which only bytecode files are stored. The audit
subsystem is recording each open failure.

Thanks,
Eldon Ziegler


Here are two suggestions:

1. Put a dummy python file in the directory that does very little, 
perhaps something like:


   print("%s: You should not be seeing this" % sys.argv[0])

Give it the name of one of the .pyc, e.g., if foo.pyc, then foo.py.

Give the bytecode file a later date, e.g., "touch foo.pyc" (assuming you 
can do that without messing up other aspects of your system.)


If that works, then copy the dummy file to each of the other required 
.py names in the directory.  You'll then have to touch *.pyc to ensure 
that the pyc's have later dates.  After that, you won't have to do 
anything when you replace a .pyc file.  When you add a new .pyc you'll 
need to do the copy and touch again.


2. Use a log truncator to truncate the audit log.

I don't remember the name of one at the moment, but I believe there is 
at least one open source program that will monitor named files and 
truncate them from the beginning to a fixed maximum size.


I don't like this method as much as the first because it might result in 
something important being truncated.


Alan

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

regex question

[rusi]

Can someone throw some light on this anomalous behavior?

>>> import re
>>> r = re.search('a(b+)', 'ababbaaab')

>>> r.group(1)
'b'
>>> r.group(0)
'ab'
>>> r.group(2)
Traceback (most recent call last):
  File "", line 1, in 
IndexError: no such group

>>> re.findall('a(b+)', 'ababbaaab')
['b', 'bb', 'b']

So evidently group counts by number of '()'s and not by number of
matches (and this is the case whether one uses match or search). So
then whats the point of search-ing vs match-ing?

Or equivalently how to move to the groups of the next match in?

[Side note: The docstrings for this really suck:

>>> help(r.group)
Help on built-in function group:

group(...)

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

Re: change gtk STOCK_SAVE label text on the fly

[Thomas Jollans]

On 29/07/11 13:02, Peter Irbizon wrote:
> Hello,
>  
> how could I change STOCK_SAVE label text? I would like to have "Save
> it!" instead of "Save"
> And other question related to this is how can I change translation of
> STOCK_SAVE on the fly? I think I need to set locale for pygtk...but
> don't know how
>
Why do you want to change it? I assume it's being used in some dialog
class you're using; which one? Does it not allow you to set the button
text when you create it?

(Don't feel you need to answer this: Do you really think you need
on-the-fly language switching? It's "cool", but how many users are going
to want to use that?)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: regex question

[Thomas Jollans]

On 29/07/11 16:53, rusi wrote:
> Can someone throw some light on this anomalous behavior?
>
 import re
 r = re.search('a(b+)', 'ababbaaab')
 r.group(1)
> 'b'
 r.group(0)
> 'ab'
 r.group(2)
> Traceback (most recent call last):
>   File "", line 1, in 
> IndexError: no such group
>
 re.findall('a(b+)', 'ababbaaab')
> ['b', 'bb', 'b']
>
> So evidently group counts by number of '()'s and not by number of
> matches (and this is the case whether one uses match or search). So
> then whats the point of search-ing vs match-ing?
>
> Or equivalently how to move to the groups of the next match in?
>
> [Side note: The docstrings for this really suck:
>
 help(r.group)
> Help on built-in function group:
>
> group(...)
>

Pretty standard regex behaviour: Group 1 is the first pair of brackets.
Group 2 is the second, etc. pp. Group 0 is the whole match.
The difference between matching and searching is that match assumes that
the start of the regex coincides with the start of the string (and this
is documented in the library docs IIRC). re.match(exp, s) is equivalent
to re.search('^'+exp, s). (if not exp.startswith('^'))

Apparently, findall() returns the content of the first group if there is
one. I didn't check this, but I assume it is documented.

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

How object's setattr differs from inherited?

[Ciantic]

>>> class MyObject(object):
... pass
...
>>> my = MyObject()
>>> my.myvar = 'value' # No error!
>>>
>>> obj = object()
>>> obj.myvar = 'value'  # Causes error!
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'object' object has no attribute 'myvar'

Why simple inheritance from object does not cause errors at setattr,
yet direct init of object() does?


I was trying to "decor" objects, lists etc with own attributes that
could be used in templates and was sadly not permitted to do so:

>>> something = [1,2]
>>> something.myvar = 'value'
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'list' object has no attribute 'myvar'

(I could "solve" this by inheriting from list, but there are cases
where I can't do so, the data is coming elsewhere and wrapping it is
ugly, adding new attribute would be neater)

But my question now is why this setattr problem happens on some types?
What are the types that usually does not allow to arbitrary setattr?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How object's setattr differs from inherited?

[Thomas Rachel]

Am 29.07.2011 17:12 schrieb Ciantic:

class MyObject(object):

... pass
...

my = MyObject()
my.myvar = 'value' # No error!

obj = object()
obj.myvar = 'value'  # Causes error!

Traceback (most recent call last):
   File "", line 1, in
AttributeError: 'object' object has no attribute 'myvar'

Why simple inheritance from object does not cause errors at setattr,
yet direct init of object() does?


I was trying to "decor" objects, lists etc with own attributes that
could be used in templates and was sadly not permitted to do so:


something = [1,2]
something.myvar = 'value'

Traceback (most recent call last):
   File "", line 1, in
AttributeError: 'list' object has no attribute 'myvar'

(I could "solve" this by inheriting from list, but there are cases
where I can't do so, the data is coming elsewhere and wrapping it is
ugly, adding new attribute would be neater)

But my question now is why this setattr problem happens on some types?
What are the types that usually does not allow to arbitrary setattr?


>>> a=object()
>>> class C(object): pass
...
>>> b=C()
>>> dir(a)
['__class__', '__delattr__', '__doc__', '__format__', 
'__getattribute__', '__hash__', '__init__', '__new__', '__reduce__', 
'__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', 
'__subclasshook__']

>>> dir(b)
['__class__', '__delattr__', '__dict__', '__doc__', '__format__', 
'__getattribute__', '__hash__', '__init__', '__module__', '__new__', 
'__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', 
'__str__', '__subclasshook__', '__weakref__']



What are the differences?

['__dict__', '__module__', '__weakref__']

As the attributes are stored in __dict__, I would suppose that it is 
__dict__ which makes the difference. object() has no such and therefore 
there is no place to save an attribute.



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

Re: regex question

[MRAB]

On 29/07/2011 16:45, Thomas Jollans wrote:

On 29/07/11 16:53, rusi wrote:

Can someone throw some light on this anomalous behavior?


import re
r = re.search('a(b+)', 'ababbaaab')
r.group(1)

'b'

r.group(0)

'ab'

r.group(2)

Traceback (most recent call last):
   File "", line 1, in
IndexError: no such group


re.findall('a(b+)', 'ababbaaab')

['b', 'bb', 'b']

So evidently group counts by number of '()'s and not by number of
matches (and this is the case whether one uses match or search). So
then whats the point of search-ing vs match-ing?

Or equivalently how to move to the groups of the next match in?

[Side note: The docstrings for this really suck:


help(r.group)

Help on built-in function group:

group(...)



Pretty standard regex behaviour: Group 1 is the first pair of brackets.
Group 2 is the second, etc. pp. Group 0 is the whole match.
The difference between matching and searching is that match assumes that
the start of the regex coincides with the start of the string (and this
is documented in the library docs IIRC). re.match(exp, s) is equivalent
to re.search('^'+exp, s). (if not exp.startswith('^'))

Apparently, findall() returns the content of the first group if there is
one. I didn't check this, but I assume it is documented.


findall returns a list of tuples (what the groups captured) if there is
more than 1 group, or a list of strings (what the group captured) if
there is 1 group, or a list of strings (what the regex matched) if
there are no groups.
--
http://mail.python.org/mailman/listinfo/python-list

Re: How object's setattr differs from inherited?

[Thomas Jollans]

On 29/07/11 17:12, Ciantic wrote:
 class MyObject(object):
> ... pass
> ...
 my = MyObject()
 my.myvar = 'value' # No error!

 obj = object()
 obj.myvar = 'value'  # Causes error!
> Traceback (most recent call last):
>   File "", line 1, in 
> AttributeError: 'object' object has no attribute 'myvar'
>
> Why simple inheritance from object does not cause errors at setattr,
> yet direct init of object() does?
>
>
> I was trying to "decor" objects, lists etc with own attributes that
> could be used in templates and was sadly not permitted to do so:
>
 something = [1,2]
 something.myvar = 'value'
> Traceback (most recent call last):
>   File "", line 1, in 
> AttributeError: 'list' object has no attribute 'myvar'
>
> (I could "solve" this by inheriting from list, but there are cases
> where I can't do so, the data is coming elsewhere and wrapping it is
> ugly, adding new attribute would be neater)
>
> But my question now is why this setattr problem happens on some types?
> What are the types that usually does not allow to arbitrary setattr?

object has pre-defined slots (instead of just storing everything is a
__dict__) -- so can your objects:

Python 3.2.1 (default, Jul 11 2011, 12:37:49)
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> class Foo:
... __slots__ = ['a', 'b']
...
>>> f = Foo()
>>> f.a = 1
>>> f.b = 1
>>> f.c = 2
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'Foo' object has no attribute 'c'
>>>


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

Re: How object's setattr differs from inherited?

[Andrew Berg]

On 2011.07.29 10:12 AM, Ciantic wrote:
 class MyObject(object):
> ... pass
> ...
 my = MyObject()
 my.myvar = 'value' # No error!

 obj = object()
 obj.myvar = 'value'  # Causes error!
> Traceback (most recent call last):
>   File "", line 1, in 
> AttributeError: 'object' object has no attribute 'myvar'
> 
> Why simple inheritance from object does not cause errors at setattr,
> yet direct init of object() does?
object objects have no __dict__. User-defined objects typically do. Each
child of MyObject would likely have __dict__ as well.

> I was trying to "decor" objects, lists etc with own attributes that
> could be used in templates and was sadly not permitted to do so:
> 
 something = [1,2]
 something.myvar = 'value'
> Traceback (most recent call last):
>   File "", line 1, in 
> AttributeError: 'list' object has no attribute 'myvar'
Lists have no __dict__, and AFAIK, there's no reason they should.

-- 
CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
PGP/GPG Public Key ID: 0xF88E034060A78FCB
-- 
http://mail.python.org/mailman/listinfo/python-list

PyWart: os.path needs immediate attention!

[rantingrick]

--
 Overview of Problems:
--

 * Too many methods exported.
 * Poor choice of method names.
 * Non public classes/methods exported!
 * Duplicated functionality.

--
 Proposed new functionality:
--

 * New path module will ONLY support one path sep! There is NO reason
to support more than one. When we support more than one path sep we
help to propagate multiplicity.We should only support the slash and
NOT the backslash across ALL OS's since the slash is more widely
accepted. If an OS does not have the capability to support only the
slash then that OS is not worthy of a Python builtin module. The users
of such OS will be responsible for managing their OWN os_legacy.path
module. We are moving forward. Those who wish to wallow in the past
will be left behind.

 * Introduce a new method named "partition" which (along with string
splitting methods) will replace the six methods "basename", "dirname",
"split", "splitdrive", "splitunc", "splittext". The method will return
a tuple of the path split into four parts: (drive, path, filename,
extension). This is the ONLY splitting method this module needs. All
other splits can use string methods.

--
 Expose of the Warts of current module:
--


~
 1. Too many methods
~

Follows is a list of what to keep and what to cull:

 + abspath
 + altsep
 - basename --> path.partition[-2]
 + commonprefix
 + curdir
 + defpath
 + devnull
 - dirname --> os.path.join(drive,path)
 + exists
 + expanduser
 + expandvars
 + extsep
 - genericpath --> should be private!
 + getatime
 + getctime
 + getmtime
 + getsize
 + isabs
 + isdir
 + isfile
 + islink
 + ismount
 + join
 - lexists --> duplicate!
 - normcase --> path = path.lower()
 - normpath --> should not need this!
 - os --> should be private!
 + pardir
 + pathsep
 + realpath
 + relpath
 + sep
 - split --> path.rsplit('/', 1)
 - splitdrive --> path.split(':', 1)
 - splitext --> path.rsplit('.')
 - splitunc --> Unix specific!
 - stat --> should be private!
 + supports_unicode_filenames --> windows specific!
 - sys --> should be private!
 + walk
 - warnings --> should be private!


~
 2. Poor Name Choices:
~

 * basename --> should be: filename
 * split --> split what?
 * splitext --> Wow, informative!

~
 3. Non Public Names Exposed!
~

 * genericpath
 * os
 * stat
 * sys
 * warnings


Note: i did not check the Unix version of os.path for this.

~
 4. Duplicated functionality.
~

>>> os.path.lexists.__doc__
'Test whether a path exists.  Returns False for broken symbolic links'
>>> os.path.exists.__doc__
'Test whether a path exists.  Returns False for broken symbolic links'

Should have been one method:
>>> os.path.exists(path, ignoreSymLnks=False)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Another win for profiling.

[Alan Meyer]

On 07/29/2011 07:46 AM, Roy Smith wrote:

It's often said that you shouldn't try to guess what's slow, but use
profiling tools to measure what's slow.  I had a great example of that
yesterday.  ...


Yes.

My first experience of profiling was about 25 years ago.  I was 
experimenting with Borland's Turbo Profiler on C code.  I thought to 
myself, What kind of clueless programmer doesn't know where his code is 
spending its time?  How useful could this be?


Then I ran the profiler and found out how clueless I really was.  The 
profiler showed me that I could change one line in a thousand line 
program and cut the run time by 50%.


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

Re: regex question

[Rustom Mody]

MRAB wrote:
> findall returns a list of tuples (what the groups captured) if there is
more than 1 group,
> or a list of strings (what the group captured) if there is 1 group, or a
list of
> strings (what the regex matched) if there are no groups.

Thanks.
It would be good to put this in the manual dont you think?

Also, the manual says in the 'match' section

"Note If you want to locate a match anywhere in *string*, use search()instead."

to guard against users using match when they should be using search.

Likewise it would be helpful if the manual also said (in the match,search
sections)
"If more than one match/search is required use findall"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: os.path needs immediate attention!

[Andrew Berg]

On 2011.07.29 12:22 PM, rantingrick wrote:
>  * New path module will ONLY support one path sep! There is NO reason
> to support more than one. When we support more than one path sep we
> help to propagate multiplicity.We should only support the slash and
> NOT the backslash across ALL OS's since the slash is more widely
> accepted. If an OS does not have the capability to support only the
> slash then that OS is not worthy of a Python builtin module. The users
> of such OS will be responsible for managing their OWN os_legacy.path
> module. We are moving forward. Those who wish to wallow in the past
> will be left behind.
So now you propose that not only does Python need drastic changes, but a
major operating system family as well (I know Windows will accept a
forward slash in some contexts, but I'd be pretty surprised if one could
completely replace the backslash with it completely)? Interesting.

>  * Introduce a new method named "partition" which (along with string
> splitting methods) will replace the six methods "basename", "dirname",
> "split", "splitdrive", "splitunc", "splittext". The method will return
> a tuple of the path split into four parts: (drive, path, filename,
> extension). This is the ONLY splitting method this module needs. All
> other splits can use string methods.
So these pretty specifically named functions (except perhaps split)
should be replaced with one ambiguously named one? Interesting.

>  - dirname --> os.path.join(drive,path)
Now you've stopped making sense completely. Also interesting.

>  * split --> split what?
> ...
 os.path.exists(path, ignoreSymLnks=False)
I actually agree with you on these, which I suppose is interesting.

-- 
CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
PGP/GPG Public Key ID: 0xF88E034060A78FCB
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 8 and extraneous whitespace

[OKB (not okblacke)]

Chris Angelico wrote:

> On Thu, Jul 28, 2011 at 4:18 PM, OKB (not okblacke)
>>        I think exactly the opposite.  The source file should re flect
>> the semantic organization of the code, without extraneous concessions
>> to visual display (like "lining things up" with spaces or splitting
>> long lines with hard newlines).  The editor should present the code
>> nicely. People already argue for this general mindset when they say
>> that "any good edit will let you set the tab width", etc. 
> 
> That mandates that formatting NOT be a part of the language. I could
> take C code and reformat it in various ways with a script, and easily
> guarantee that the script won't affect the code by simply having it
> only ever adjust whitespace. This concept simply won't work in Python.

"Formatting" is too general a term.  Obviously "formatting" in 
the lay sense is part of any language, since things like commas and 
parentheses matter.  What Python does that's unusual is pay attention to 
INDENTATION, which is a very specific part of formatting involving 
whitespace at the beginning of a line.  This isn't incompatible with 
what I outlined above.
 
> Personally, I like to be able to format things according to where they
> came from, or other criteria. Take a look at this code, for instance;
> the post has highlighted the difference between 1 and 0, but otherwise
> hasn't changed it:
> 
> http://thedailywtf.com/Articles/The-Shapes.aspx
> 
> Note how the formatting is beautifully consistent. Each line is
> wrapped to a tidy 70 characters, or whatever it is (I haven't
> counted). Each data row, therefore, has the same number of characters
> in it. But is that useful? Would it not be far more useful to wrap
> them each at their image widths? Yes, it might take a bit more
> vertical space, but the source code would *look like the image* and
> that massively helps readability. This is why a source code tidying
> script can't fully grok readability; if a program looks at a sequence
> of strings, how can it know where to break them? All of these
> (hypothetical) examples are single string literals, broken across
> lines:
> 
> -
> "This is string 1.\0"
> "This is string 2, and it is longer.\0"
> "String 3.\0"
> -
> "This is a long paragraph of"
> "text, which I have wrapped somewhat messily, and"
> "which a good text"
> "tidying program should be able to clean up"
> "for me."
> -
> "Usage: programname [options] [argument]\n"
> "-f\tFooify\n"
> "-b\tBarify\n"
> "\n"
> "argument should be either '5-minute' or 'course'\n"
> -
> 
> Can you write a script that perfectly handles these sorts of literals?
> Considering that the divider in the first one might not be \0, but
> might be any character or even string of characters, it's not really
> possible for an editor to know where to wrap something; which means
> that it's up to the programmer to make things readable. And that
> demands that the programmer know what he's doing, and that the
> programmer have the power to express what he's doing how he chooses.
> Overly-strict formatting rules/guides remove that power.

I don't think I understand what you're getting at there.  What 
would you mean "handling" those string literals?  I'm just talking about 
an editor that displays things in a way that respects semantic 
indentation that you put in.  I'm not talking about some sort of 
"script" that would take your second two examples and make them look 
nice.  The editor would need to know Python's string literal syntax to 
do that.  If you want to write things in those ways, okay, but my 
preference would be to always write them as one big string literal 
(e.g., triple-quoted), and then have the editor strip away shared 
indentation.

So I guess I was a bit unclear when I said "the editor should 
present the code nicely".  I just mean that the editor should present 
the code in a way that reflects the semantic indentation present, thus 
relieving users of the need to insert redundant linebreaks and 
whitespace to make things "line up".  I don't mean that it should try to 
"prettify" things in the way you seem to be suggesting.

As an aside, I don't think string literals are a great example case 
for these issues.  ALL whitespace (not just indentation), and all 
of everything else, always matters in string literals, so you do indeed 
have to put in explicit whitespace if you want explicit whitespace in 
the string.  In code, though, explicit whitespace is only needed to 
indicate semantically meaningful stuff, so you should only use it for 
that, and the editor should insert "visual space" (without actual 
whitespace characters in the file) to make things like up at the 
semantic indentation levels.

-- 
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is
no path, and leave a trail."
--author unknown
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is it bad practise to write __all__ like that

[OKB (not okblacke)]

Thomas Rachel wrote:

> class AllList(list):
>  """list which can be called in order to be used as a
>  __all__-adding 
> decorator"""

Wow, this is a great idea.

-- 
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is
no path, and leave a trail."
--author unknown
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: list comprehension to do os.path.split_all ?

[Carl Banks]

On Thursday, July 28, 2011 2:31:43 PM UTC-7, Ian wrote:
> On Thu, Jul 28, 2011 at 3:15 PM, Emile van Sebille  wrote:
> > On 7/28/2011 1:18 PM gry said...
> >>
> >> [python 2.7] I have a (linux) pathname that I'd like to split
> >> completely into a list of components, e.g.:
> >>    '/home/gyoung/hacks/pathhack/foo.py'  -->   ['home', 'gyoung',
> >> 'hacks', 'pathhack', 'foo.py']
> >>
> >> os.path.split gives me a tuple of dirname,basename, but there's no
> >> os.path.split_all function.
> >>
> >
> > Why not just split?
> >
> > '/home/gyoung/hacks/pathhack/foo.py'.split(os.sep)
> 
> Using os.sep doesn't make it cross-platform. On Windows:
> 
> >>> os.path.split(r'C:\windows')
> ('C:\\', 'windows')
> >>> os.path.split(r'C:/windows')
> ('C:/', 'windows')
> >>> r'C:\windows'.split(os.sep)
> ['C:', 'windows']
> >>> r'C:/windows'.split(os.sep)
> ['C:/windows']

It's not even fullproof on Unix.

'/home//h1122/bin///ghi/'.split('/')

['','home','','bin','','','ghi','']

The whole point of the os.path functions are to take care of whatever oddities 
there are in the path system.  When you use string manipulation to manipulate 
paths, you bypass all of that and leave yourself open to those oddities, and 
then you find your applications break when a user enters a doubled slash.

So stick to os.path.


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

What is xrange?

[Billy Mays]

Is xrange not a generator?  I know it doesn't return a tuple or list, so 
what exactly is it?  Y doesn't ever complete, but x does.


x = (i for i in range(10))
y = xrange(10)

print "===X==="
while True:
for i in x:
print i
break
else:
break

print "===Y==="
while True:
for i in y:
print i
break
else:
break
--
http://mail.python.org/mailman/listinfo/python-list

removing nested iffs

[Josh Benner]

I'm writing a function to create a string that gets longer iff an argument
is defined.  In there a more elegant way than nesting all those ifs?

def format_rsync_src_string(args, server="RSYNC"):
""" Format an rsync source directory string. """
if args.server is None:
raise CopyNightlyError("No rsync server provided.")
src = "{0}::".format(args.server)
if args.project not None:
src += "{0}/".format(args.project)
if args.version not None:
src += "{0}/".format(args.version)
if args.build not None:
src += "Build {0}".format(args.build)
return src
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: os.path needs immediate attention!

[harrismh777]

Andrew Berg wrote:

  * New path module will ONLY support one path sep! There is NO reason

 to support more than one. When we support more than one path sep we
 help to propagate multiplicity.We should only support the slash and
 NOT the backslash across ALL OS's since the slash is more widely
 accepted. If an OS does not have the capability to support only the
 slash then that OS is not worthy of a Python builtin module. The users
 of such OS will be responsible for managing their OWN os_legacy.path
 module. We are moving forward. Those who wish to wallow in the past
 will be left behind.


I actually agree with this.  Like Timon once told Pumbaa, "Ya gotta put 
your behind in the past. . . "


The backslash sep is an asinine CPM/80 | DOS disk based carry-over which 
does not fit well with the modern forward direction. The disk based file 
system carry-over is bad enough; but, propagating multiple ways of doing 
simple things like specifying file-system paths is not helpful in any 
context.


The modern direction today (almost universally on the server-side) is to 
specify the path from the root "/" regardless of physical disk array 
geometries (or physical drives "C:\"). The forward slash actually makes 
some philosophical sense, and of course is more aesthetically pleasing.


So, let's put our behinds in the past and slash forward !





--
m harris

FSF  ...free as in freedom/
http://webpages.charter.net/harrismh777/gnulinux/gnulinux.htm
--
http://mail.python.org/mailman/listinfo/python-list

Re: What is xrange?

[harrismh777]

Billy Mays wrote:

Is xrange not a generator?  I know it doesn't return a tuple or list, so
what exactly is it?  Y doesn't ever complete, but x does.


 range(n) creates a list containing all the integers 0..n-1. This 
is a problem if you do range(100), because you'll end up with a >4Mb 
list. xrange deals with this by returning an object that pretends to be 
a list, but just works out the number needed from the index asked for, 
and returns that.


 range() can actually be faster in some cases - eg. if iterating 
over the same sequence multiple times. xrange has to reconstruct the 
integer object every time, but range will have real integer objects. (It 
will always perform worse in terms of memory however)


 xrange isn't usable in all cases where a real list is needed. For 
instance, it doesn't support slices, or any list methods.




--
m harris

FSF  ...free as in freedom/
http://webpages.charter.net/harrismh777/gnulinux/gnulinux.htm
--
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: os.path needs immediate attention!

[Waldek M.]

Dnia Fri, 29 Jul 2011 14:41:22 -0500, harrismh777 napisał(a):
> The backslash sep is an asinine CPM/80 | DOS disk based carry-over which 
> does not fit well with the modern forward direction. The disk based file 
> system carry-over is bad enough; but, propagating multiple ways of doing 
> simple things like specifying file-system paths is not helpful in any 
> context.

Please, do tell it to Microsoft. And once you've convinced them,
and they've implemented it, do report :-)

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

Re: removing nested iffs

[Wolfgang Rohdewald]

On Freitag 29 Juli 2011, Josh Benner wrote:
> if args.build not None:

which python version understands this?

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

Re: PyWart: os.path needs immediate attention!

[Teemu Likonen]

* 2011-07-29T10:22:04-07:00 *  wrote:

>  * New path module will ONLY support one path sep! There is NO reason
> to support more than one.

Pathnames and the separator for pathname components should be abstracted
away, to a pathname object. This pathname object could have a "path" or
"directory" slot which is a list of directory components (strings). Then
there would be method like "to_namestring" which converts a pathname
object to native pathname string. It takes care of any platform-specific
stuff like pathname component separators. Of course "to_pathname" method
is needed too. It converts system's native pathname string to a pathname
object.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: removing nested iffs

[Josh Benner]

On Fri, Jul 29, 2011 at 1:07 PM, Wolfgang Rohdewald
wrote:

> On Freitag 29 Juli 2011, Josh Benner wrote:
> > if args.build not None:
>
> which python version understands this?
>
> --
> Wolfgang
>

Apparently the version running in my head understands it ;-)

Sorry about that how about this (replacing 'not' with 'is not' where
appropriate):


def format_rsync_src_string(args, server="RSYNC"):
""" Format an rsync source directory string. """
if args.server is None:
raise CopyNightlyError("No rsync server provided.")
src = "{0}::".format(args.server)
if args.project is not None:
src += "{0}/".format(args.project)
if args.version is not None:
src += "{0}/".format(args.version)
if args.build is not None:
src += "Build {0}".format(args.build)
return src
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: list comprehension to do os.path.split_all ?

[Alexander Kapps]

On 29.07.2011 21:30, Carl Banks wrote:


It's not even fullproof on Unix.

'/home//h1122/bin///ghi/'.split('/')

['','home','','bin','','','ghi','']

The whole point of the os.path functions are to take care of whatever oddities 
there are in the path system.  When you use string manipulation to manipulate 
paths, you bypass all of that and leave yourself open to those oddities, and 
then you find your applications break when a user enters a doubled slash.

So stick to os.path.


Carl Banks


This would also be fixed with normpath() as Dennis Lee Bieber 
suggested. And my solution with list comprehensions handles this too.


Still, there might be other path oddities which would break here. I 
think, that something like a split_all() function should be 
available in the stdlib, no?


Actually, it isn't the first time, where I wonder why 
os.path.split() doesn't do this already. I mean, str.split() doesn't 
only split on the first part, right?

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

Re: PyWart: os.path needs immediate attention!

[Chris Angelico]

On Sat, Jul 30, 2011 at 3:22 AM, rantingrick  wrote:
> ~
>  3. Non Public Names Exposed!
> ~
>
>  * genericpath
>  * os
>  * stat
>  * sys
>  * warnings
>

And you intend to do what, exactly, with these?

>  - splitunc --> Unix specific!

1) So?
2) http://docs.python.org/library/os.path.html#os.path.splitunc says
"Availability: Windows."

If you actually meant "Windows specific" then the first one still holds.

Under Unix, the only place UNC names are supported is CIFS mounting
(and equivalents, smbmount etc).

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

Re: What is xrange?

[Thomas Jollans]

On 29/07/11 21:36, Billy Mays wrote:
> Is xrange not a generator?  I know it doesn't return a tuple or list,
> so what exactly is it?  Y doesn't ever complete, but x does.
>
> x = (i for i in range(10))
> y = xrange(10)
>
> print "===X==="
> while True:
> for i in x:
> print i
> break
> else:
> break
>
> print "===Y==="
> while True:
> for i in y:
> print i
> break
> else:
> break

Every for loop calls gets a new iterator from the object you're
iterating over. (__iter__) -- Apparently, xrange is implemented in such
a way (as are lists) that you can iterate over the object many times,
while each generator object (and how could it be otherwise can only be
iterated over once. What is xrange(foo)? It is an object that supports
list-like indices, the iterator protocol, and probably a few other
things that you will find in the stdlib docs. Generators also support
the iterator protocol, but that's about as far as the similarity goes
(in general)

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

Re: regex question

[Thomas Jollans]

On 29/07/11 19:52, Rustom Mody wrote:
> MRAB wrote:
> > findall returns a list of tuples (what the groups captured) if there
> is more than 1 group,
> > or a list of strings (what the group captured) if there is 1 group,
> or a list of
> > strings (what the regex matched) if there are no groups.
>
> Thanks.
> It would be good to put this in the manual dont you think?
It is in the manual.
>
> Also, the manual says in the 'match' section
>
> "Note If you want to locate a match anywhere in /string/, use search()
> instead."
>
> to guard against users using match when they should be using search.
>
> Likewise it would be helpful if the manual also said (in the
> match,search sections)
> "If more than one match/search is required use findall"
>
>

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

Re: What is xrange?

[Jerry Hill]

On Fri, Jul 29, 2011 at 3:36 PM, Billy Mays  wrote:
> Is xrange not a generator?  I know it doesn't return a tuple or list, so
> what exactly is it?  Y doesn't ever complete, but x does.
>
> x = (i for i in range(10))
> y = xrange(10)

xrange() does not return a generator.  It returns an iterable xrange
object.  If you want the iterator derived from the iterable xrange
object, you can get it like this:  iterator = y.__iter__()

See http://docs.python.org/library/functions.html#xrange for the
definition of the xrange object.

http://www.learningpython.com/2009/02/23/iterators-iterables-and-generators-oh-my/
seems to cover the differences between iterables, iterators, and
generators pretty well.

Some more reading:
http://docs.python.org/howto/functional.html
http://www.python.org/dev/peps/pep-0255/
http://www.python.org/dev/peps/pep-0289/

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

Re: removing nested iffs

[Peter Otten]

Josh Benner wrote:

> I'm writing a function to create a string that gets longer iff an argument
> is defined.  In there a more elegant way than nesting all those ifs?
> 
> def format_rsync_src_string(args, server="RSYNC"):
> """ Format an rsync source directory string. """
> if args.server is None:
> raise CopyNightlyError("No rsync server provided.")
> src = "{0}::".format(args.server)
> if args.project not None:
> src += "{0}/".format(args.project)
> if args.version not None:
> src += "{0}/".format(args.version)
> if args.build not None:
> src += "Build {0}".format(args.build)
> return src

How about 

def format_pairs(pairs):
for template, value in pairs:
if value is None:
break
yield template.format(value)

def format_rsync_src_string(args, server="RSYNC"):
""" Format an rsync source directory string. """
if args.server is None:
raise CopyNightlyError("No rsync server provided.")

return "".join(format_pairs([
("{0}::", args.server),
("{0}/", args.project),
("{0}/", args.version),
("Build {0}", args.build)]))


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

Re: PyWart: os.path needs immediate attention!

[Corey Richardson]

Excerpts from rantingrick's message of Fri Jul 29 13:22:04 -0400 2011:
> --
>  Proposed new functionality:
> --
>
>  * New path module will ONLY support one path sep! There is NO
> reason to support more than one. When we support more than one path
> sep we help to propagate multiplicity.We should only support the
> slash and NOT the backslash across ALL OS's since the slash is more
> widely accepted. If an OS does not have the capability to support
> only the slash then that OS is not worthy of a Python builtin
> module. The users of such OS will be responsible for managing their
> OWN os_legacy.path module. We are moving forward. Those who wish to
> wallow in the past will be left behind.

People who use windows are used to \ being their pathsep. If you show
them a path that looks like C:/whatever/the/path in an app, they are
going to think you are nuts. It isn't up to us to decide what anyone
uses as a path separator. They use \ natively, so should we. If at
any point Windows as an OS starts using /'s, and not support, actually
uses (in Windows Explorer as default (or whatever the filebrowser's
name is)), it would be great to switch over.

> * Introduce a new method named "partition" which (along with string
> splitting methods) will replace the six methods "basename",
> "dirname", "split", "splitdrive", "splitunc", "splittext". The
> method will return a tuple of the path split into four parts:
> (drive, path, filename, extension). This is the ONLY splitting
> method this module needs. All other splits can use string methods.

I agree, although what if one wants to further split the returned
path, in an OS-independent way? Just because we want all pathseps
to be /, doesn't mean they are (and I personally don't care either
way).

> ~ 1. Too many methods ~
> 
> Follows is a list of what to keep and what to cull:
> 
>  + abspath
>  + altsep
>  - basename --> path.partition[-2]
>  + commonprefix
>  + curdir
>  + defpath
>  + devnull
>  - dirname --> os.path.join(drive,path)
>  + exists
>  + expanduser
>  + expandvars
>  + extsep
>  - genericpath --> should be private!
>  + getatime
>  + getctime
>  + getmtime
>  + getsize
>  + isabs
>  + isdir
>  + isfile
>  + islink
>  + ismount
>  + join
>  - lexists --> duplicate!
>  - normcase --> path = path.lower()

Not quite, here are a few implementations of normcase (pulled from 2.7)

# NT
def normcase(s):
"""Normalize case of pathname.  



Makes all characters lowercase and all slashes into backslashes."""
return s.replace("/", "\\").lower()

# Mac (Correct in this case)

def normcase(path):
return path.lower()

# POSIX

def normcase(s):
"""Normalize case of pathname.  Has no effect under Posix"""
return s


But I can't think of where I would ever use that. Isn't case important on
Windows? 

>  - normpath --> should not need this!

Why not? It provides an OS-independent way to make the pathname look pretty,
maybe for output? I don't really see a use for it, to be honest. But I'd 
rather there be a working solution in the stdlib than have everyone need to
throw in their own that might not handle some things properly. Talk about
multiplicity!

>  - os --> should be private!
>  + pardir
>  + pathsep
>  + realpath
>  + relpath
>  + sep
>  - split --> path.rsplit('/', 1)

And on those operating systems where "\\" is the pathsep?

>  - splitdrive --> path.split(':', 1)
>  - splitunc --> Unix specific!

Err...no. It's for UNC paths, as in  \\server\mount\foo\bar. It's not even
in posixpath.py, so in no way could it ever be Unix specific.

>  - stat --> should be private!
>  + supports_unicode_filenames --> windows specific!
>  - sys --> should be private!
>  + walk
>  - warnings --> should be private!
> 
> 
> ~
>  2. Poor Name Choices:
> ~
> 
>  * basename --> should be: filename

I agree. The name is a carryover from basename(1) and I guess it's good for
those people, but it certainly isn't the least surprising name. If anything,
I would think the base is everything before!

>  * split --> split what?

The path, of course. On its own, it's uninformative, but considering
the whole name is "os.path.split", it's fairly intuitive.

>  * splitext --> Wow, informative!

split extension...seems straightforward to me.

> ~
>  4. Duplicated functionality.
> ~
> 
> >>> os.path.lexists.__doc__
> 'Test whether a path exists.  Returns False for broken symbolic links'
> >>> os.path.exists.__doc__
> 'Test whether a path exists.  Returns False for broken symbolic links'
> 
> Should have been one method:
> >>> os.path

Re: removing nested iffs

[Chris Angelico]

On Sat, Jul 30, 2011 at 5:40 AM, Josh Benner  wrote:
> I'm writing a function to create a string that gets longer iff an argument
> is defined.  In there a more elegant way than nesting all those ifs?

Your logic appears to be: Proceed along a specified list and stop when
you find that you don't have the corresponding information (meaning
that args.build will be ignored if args.project==None). I'd do that
with multiple return statements:

src = args.server + "::"
if not args.project: return src
src += args.project + "/"
if not args.version: return src
# etc

Note that I'm converting to bool ("if not blah") instead of explicitly
checking for None. If an empty string is a valid
project/version/build, change this back to the "is not None" syntax.

I wouldn't bother with format() when it's simply putting a string on
one side or the other of something; simpler just to add two strings
together (and probably faster, but profile before you pick based on
that).

On the other hand, if your if statements are the unusual case and
maybe an error, it might be easier to do this:

try:
 src = args.server + "::"
 src += args.project + "/"
 src += args.version + "/"
 src += "Build " + args.build
except TypeError:
 pass
return src

Attempting to concatenate None to a string raises TypeError "Can't
convert 'NoneType' object to str implicitly" on my Python 3.2, and on
Python 2.4 and 2.6, a TypeError "cannot concatenate 'str' and
'NoneType' objects". Check what your version does. In any case, the
above try/except will bail out without error when it gets a TypeError
of any sort, so be sure this won't be a problem to you!

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

Re: PEP 8 and extraneous whitespace

[Chris Angelico]

On Sat, Jul 30, 2011 at 4:45 AM, OKB (not okblacke)
 wrote:
> Chris Angelico wrote:
>> That mandates that formatting NOT be a part of the language. I could
>> take C code and reformat it in various ways with a script, and easily
>> guarantee that the script won't affect the code by simply having it
>> only ever adjust whitespace. This concept simply won't work in Python.
>
>        "Formatting" is too general a term.  Obviously "formatting" in
> the lay sense is part of any language, since things like commas and
> parentheses matter.  What Python does that's unusual is pay attention to
> INDENTATION, which is a very specific part of formatting involving
> whitespace at the beginning of a line.  This isn't incompatible with
> what I outlined above.

My notion of "formatting" of code is entirely whitespace, but it
includes such things as:

-
int
declspec(DLLEXPORT) foofunc(
char *str,
int num
) {
  printf("%s: %d",
str,num);
  return 1;
}
-
int declspec(DLLEXPORT) foofunc(char *str,int num)
{
printf("%s: %d", str, num);
return 1;
}
-

There's a lot of difference between these two, in terms of
readability, but it wouldn't be hard to write a script that could
format the code into your preferred form. It would be far stricter
than I would like to use, but if you have a gigantic mess of code and
you want to start comprehending it (think IOCCC entries), these sorts
of code reformatters are excellent.

>        I don't think I understand what you're getting at there.  What
> would you mean "handling" those string literals?

What I mean is that these string literals are broken across multiple
lines in a way that is meaningful to the human. Doing them with
triple-quoted strings and actual newlines is potentially restrictive;
if you're trying to build up a string of strings (like for a DOS
environment block - each NAME=VALUE pair is followed by a \0 and the
last one by another \0) that could contain newlines, it's better not
to have actual newlines in the string. Of course, there are other
options (make a list of strings, then "\0".join(lst) to make your
final string), but there are times when it's cleanest to simply have a
string literal that consists of multiple lines of source code,
irrespective of newlines in the string.

>        So I guess I was a bit unclear when I said "the editor should
> present the code nicely".  I just mean that the editor should present
> the code in a way that reflects the semantic indentation present, thus
> relieving users of the need to insert redundant linebreaks and
> whitespace to make things "line up".  I don't mean that it should try to
> "prettify" things in the way you seem to be suggesting.

Okay, so you're talking about something a lot narrower than I thought
you were. That's fine then; indentation is much simpler and easier to
manage!

>        As an aside, I don't think string literals are a great example case
> for these issues.  ALL whitespace (not just indentation), and all
> of everything else, always matters in string literals, so you do indeed
> have to put in explicit whitespace if you want explicit whitespace in
> the string.

That's precisely why abutting is supported for literal concatenation:
>>> "foo" "bar"
'foobar'

>>> ("foo"
"bar")
'foobar'

Suppose you want to have a lengthy piece of text embedded in your
source code, which you will then pass to a GUI widget for display. You
want the widget to handle word wrap, so you don't want internal line
breaks getting in the way, but you want the source code to be wrapped.
What's the best way to do this? I've never been a fan of string
literals needing run-time adjustments (like stripping indentation from
triple-quoted strings - it usually depends on the indent on the second
line, and what if you want that second line to be differently indented
from the others?), so to my mind the cleanest way would be abuttal:

"Lorem ipsum dolor sit amet, consectetur "
"adipiscing elit. Fusce fermentum posuere "
"mi eget molestie. Nulla facilisi. Curabitur "
"et ultrices massa."

The code's indented four spaces, but I don't have to strip them from
the string. (Depending on context, I might need to put parens around
that to force it to be parsed as a single string. Small potatoes.)

  In code, though, explicit whitespace is only needed to
> indicate semantically meaningful stuff, so you should only use it for
> that, and the editor should insert "visual space" (without actual
> whitespace characters in the file) to make things like up at the
> semantic indentation levels.

Interesting concept. This suggests that your source file does not
actually have the indentation, but the display does. This is an
interesting way of dealing with triple-quoted strings.

foo = """This is line 1.
This is line 2.
Line 3."""
print(foo)

If that displayed indented, maybe with a faint vertical line showing
the string's left margin, that would greatly improve readability. Any
editor that doesn't supp

Re: PyWart: os.path needs immediate attention!

[Alister Ware]

On Fri, 29 Jul 2011 10:22:04 -0700, rantingrick wrote:

> --
>  Overview of Problems:
> --
> 
>  * Too many methods exported.
>  * Poor choice of method names.
>  * Non public classes/methods exported!
>  * Duplicated functionality.
> 
> --
>  Proposed new functionality:
> --
> 
>  * New path module will ONLY support one path sep! There is NO reason
> to support more than one. When we support more than one path sep we help
> to propagate multiplicity.We should only support the slash and NOT the
> backslash across ALL OS's since the slash is more widely accepted. If an
> OS does not have the capability to support only the slash then that OS
> is not worthy of a Python builtin module. The users of such OS will be
> responsible for managing their OWN os_legacy.path module. We are moving
> forward. Those who wish to wallow in the past will be left behind.
> 
>  * Introduce a new method named "partition" which (along with string
> splitting methods) will replace the six methods "basename", "dirname",
> "split", "splitdrive", "splitunc", "splittext". The method will return a
> tuple of the path split into four parts: (drive, path, filename,
> extension). This is the ONLY splitting method this module needs. All
> other splits can use string methods.
> 
> --
>  Expose of the Warts of current module:
> --
> 
> 
> ~
>  1. Too many methods
> ~
> 
> Follows is a list of what to keep and what to cull:
> 
>  + abspath + altsep - basename --> path.partition[-2]
>  + commonprefix + curdir + defpath + devnull - dirname -->
>  os.path.join(drive,path)
>  + exists + expanduser + expandvars + extsep - genericpath --> should be
>  private!
>  + getatime + getctime + getmtime + getsize + isabs + isdir + isfile +
>  islink + ismount + join - lexists --> duplicate!
>  - normcase --> path = path.lower()
>  - normpath --> should not need this!
>  - os --> should be private!
>  + pardir + pathsep + realpath + relpath + sep - split -->
>  path.rsplit('/', 1)
>  - splitdrive --> path.split(':', 1)
>  - splitext --> path.rsplit('.')
>  - splitunc --> Unix specific!
>  - stat --> should be private!
>  + supports_unicode_filenames --> windows specific!
>  - sys --> should be private!
>  + walk - warnings --> should be private!
> 
> 
> ~
>  2. Poor Name Choices:
> ~
> 
>  * basename --> should be: filename * split --> split what?
>  * splitext --> Wow, informative!
> 
> ~
>  3. Non Public Names Exposed!
> ~
> 
>  * genericpath * os * stat * sys * warnings
> 
> 
> Note: i did not check the Unix version of os.path for this.
> 
> ~
>  4. Duplicated functionality.
> ~
> 
 os.path.lexists.__doc__
> 'Test whether a path exists.  Returns False for broken symbolic links'
 os.path.exists.__doc__
> 'Test whether a path exists.  Returns False for broken symbolic links'
> 
> Should have been one method:
 os.path.exists(path, ignoreSymLnks=False)

so far all I have is posts stating that everything is wrong.

instead of all this negativity why don't you try being productive for a 
change either make a suggestion for an addition (ie something that does 
not yest exits) or better yet give us all the benefit of your supreme 
coding talent & provide some code?



-- 
One expresses well the love he does not feel.
-- J.A. Karr
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: os.path needs immediate attention!

[Andrew Berg]

On 2011.07.29 04:21 PM, Alister Ware wrote:
> instead of all this negativity why don't you try being productive for a 
> change either make a suggestion for an addition (ie something that does 
> not yest exits) or better yet give us all the benefit of your supreme 
> coding talent & provide some code?
Because trolling the group is apparently more fun, even though most of
the regulars here know he's trolling.

-- 
CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
PGP/GPG Public Key ID: 0xF88E034060A78FCB
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: os.path needs immediate attention!

[Chris Angelico]

On Sat, Jul 30, 2011 at 6:44 AM, Corey Richardson  wrote:
> Excerpts from rantingrick's message of Fri Jul 29 13:22:04 -0400 2011:
>>  * New path module will ONLY support one path sep!
>
> People who use windows are used to \ being their pathsep. If you show
> them a path that looks like C:/whatever/the/path in an app, they are
> going to think you are nuts. It isn't up to us to decide what anyone
> uses as a path separator. They use \ natively, so should we. If at
> any point Windows as an OS starts using /'s, and not support, actually
> uses (in Windows Explorer as default (or whatever the filebrowser's
> name is)), it would be great to switch over.

Just tested this: You can type c:/foldername into the box at the top
of a folder in Explorer, and it works. It will translate it to
c:\foldername though.

We are not here to talk solely to OSes. We are here primarily to talk
to users. If you want to display a path to the user, it's best to do
so in the way they're accustomed to - so on Windows, display
backslashes.

>>  - normcase --> path = path.lower()
>
> Not quite, here are a few implementations of normcase (pulled from 2.7)
>
> # NT
>    return s.replace("/", "\\").lower()
>
> # Mac (Correct in this case)
>    return path.lower()
>
> # POSIX
>    return s
>
> But I can't think of where I would ever use that. Isn't case important on
> Windows?

No, as is demonstrated by the three above; case isn't important on
Windows, but it is on Unix.

>>  - normpath --> should not need this!
>
> Why not? It provides an OS-independent way to make the pathname look pretty,
> maybe for output? I don't really see a use for it, to be honest.

See above, we talk to users.

> But I'd
> rather there be a working solution in the stdlib than have everyone need to
> throw in their own that might not handle some things properly.

Absolutely!
>>  * basename --> should be: filename
>
> I agree. The name is a carryover from basename(1) and I guess it's good for
> those people, but it certainly isn't the least surprising name. If anything,
> I would think the base is everything before!

Agreed that it's an odd name; to me, "basename" means no path and no
extension - the base name from r"c:\foo\bar\quux.txt" is "quux".
Unfortunately that's not what this function returns, which would be
"quux.txt".

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

Re: removing nested iffs

[Chris Angelico]

On Sat, Jul 30, 2011 at 6:42 AM, Peter Otten <__pete...@web.de> wrote:
> def format_pairs(pairs):
>    for template, value in pairs:
>        if value is None:
>            break
>        yield template.format(value)
>

Cool! May I suggest a trifling change:

def format_pairs(*pairs):
for template, value in pairs:
if value is None: break
yield template.format(value)

That way, the call can dispense with the [] in the argument list. This
is a pretty clean solution though, I like it.

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

Re: change gtk STOCK_SAVE label text on the fly

[Peter Irbizon]

> (Don't feel you need to answer this: Do you really think you need
on-the-fly language switching? It's "cool", but how many users are going
to want to use that?)
yes, you're right. anyway it's cool feature and I hoped it's easy to do it
in python / but it isn't...

> Why do you want to change it? I assume it's being used in some dialog
> class you're using; which one? Does it not allow you to set the button
> text when you create it?
I tried to do that in pygtk but no success. I thought this will be quick fix
because my newbie knowledge does not allow me to set/change locale when app
starts. Of course I would prefer another way of doing this but how can I
tell to gtk which language use ?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: change gtk STOCK_SAVE label text on the fly

[Thomas Jollans]

On 30/07/11 00:29, Peter Irbizon wrote:
>> (Don't feel you need to answer this: Do you really think you need
> on-the-fly language switching? It's "cool", but how many users are going
> to want to use that?)
> yes, you're right. anyway it's cool feature and I hoped it's easy to do
> it in python / but it isn't... 
>  
>> Why do you want to change it? I assume it's being used in some dialog
>> class you're using; which one? Does it not allow you to set the button
>> text when you create it?
> I tried to do that in pygtk but no success. I thought this will be quick
> fix because my newbie knowledge does not allow me to set/change locale
> when app starts. Of course I would prefer another way of doing this but
> how can I tell to gtk which language use ?
> 
> 

http://docs.python.org/py3k/library/locale.html

I assume that whatever component uses STOCK_SAVE can be told to use
something else.
-- 
http://mail.python.org/mailman/listinfo/python-list

Identical descriptor value, without leaking memory?

[Jack Bates]

How can you get a descriptor to return an identical value, each time
it's called with the same "instance" - without leaking memory?


#!/usr/bin/env python

class descriptor:
  class __metaclass__(type):
def __get__(self, instance, owner):
  ...

class owner:
  descriptor = descriptor

instance = owner()


I want ">>> instance.descriptor is instance.descriptor" to evaluate True

I was thinking of "caching" descriptor return values? Like a dictionary
of instances and descriptor return values? I was thinking of using
weakref.WeakKeyDictionary to avoid leaking memory? But I can't guarantee
that the descriptor return value won't indirectly reference the
instance, in which case weakref.WeakKeyDictionary *does* leak memory?

Does anyone know how to get a descriptor to return an identical value,
each time it's called with the same "instance" - without leaking memory?

Much thanks!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Identical descriptor value, without leaking memory?

[Ian Kelly]

On Mon, Jul 25, 2011 at 11:46 AM, Jack Bates  wrote:
> How can you get a descriptor to return an identical value, each time
> it's called with the same "instance" - without leaking memory?

class MyDescriptor(object):
def __get__(self, instance, owner):
try:
return instance.__cached_value[self]
except AttributeError:
instance.__cached_value = {self: get_value(instance, owner)}
except KeyError:
instance.__cached_value[self] = get_value(instance, owner)
return instance.__cached_value

class MyClass(object):
my_attribute = MyDescriptor()


Placing the cache on the object instance ensures that it won't outlive
the object, and since the full attribute name will be
_MyDescriptor__cached_value, it's highly unlikely to conflict with an
existing attribute.  Keying the value on self is necessary in case the
object has multiple descriptors of the same type.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Identical descriptor value, without leaking memory?

[Ian Kelly]

On Fri, Jul 29, 2011 at 5:01 PM, Ian Kelly  wrote:
> On Mon, Jul 25, 2011 at 11:46 AM, Jack Bates  wrote:
>> How can you get a descriptor to return an identical value, each time
>> it's called with the same "instance" - without leaking memory?

Oops, that should have been:

class MyDescriptor(object):
def __get__(self, instance, owner):
try:
return instance.__cached_value[self]
except AttributeError:
instance.__cached_value = {self: get_value(instance, owner)}
except KeyError:
instance.__cached_value[self] = get_value(instance, owner)
return instance.__cached_value[self]

class MyClass(object):
my_attribute = MyDescriptor()
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: os.path needs immediate attention!

[Terry Reedy]

On 7/29/2011 1:22 PM, rantingrick wrote:


  * Introduce a new method named "partition" which (along with string
splitting methods) will replace the six methods "basename", "dirname",
"split", "splitdrive", "splitunc", "splittext". The method will return
a tuple of the path split into four parts: (drive, path, filename,
extension).


A named tuple would be an even better return, so one could refer to the 
parts as t.drive, etc.



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

Re: list comprehension to do os.path.split_all ?

[Michael Poeltl]

* Alexander Kapps  [2011-07-29 22:30]:
> On 29.07.2011 21:30, Carl Banks wrote:
>
>> It's not even fullproof on Unix.
>>
>> '/home//h1122/bin///ghi/'.split('/')
>>
>> ['','home','','bin','','','ghi','']
what about this?
>>> ' '.join('/home//h1122/bin///ghi/'.split('/')).split()  
['home', 'h1122', 'bin', 'ghi'] 
>>> 
;-) 
regards 
Michael

>> Carl Banks
>
> This would also be fixed with normpath() as Dennis Lee Bieber suggested. 
> And my solution with list comprehensions handles this too.
>
> Still, there might be other path oddities which would break here. I  
> think, that something like a split_all() function should be available in 
> the stdlib, no?
>
> Actually, it isn't the first time, where I wonder why os.path.split() 
> doesn't do this already. I mean, str.split() doesn't only split on the 
> first part, right?
> -- 
> http://mail.python.org/mailman/listinfo/python-list
>

-- 
Michael Poeltl
Computational Materials Physics  voice: +43-1-4277-51409
Univ. Wien, Sensengasse 8/12 fax:   +43-1-4277-9514 (or 9513) 
A-1090 Wien, AUSTRIA   cmp.mpi.univie.ac.at 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: os.path needs immediate attention!

[Michael Poeltl]

join 'Python-Dev'-mailinglist and tell them!
from now on I will just ignore threads you initiated

does trolling really make that much fun?
* rantingrick  [2011-07-29 19:25]:
> 
> --
>  Overview of Problems:
> --
> 
>  * Too many methods exported.
>  * Poor choice of method names.
>  * Non public classes/methods exported!
>  * Duplicated functionality.
> 
> --
>  Proposed new functionality:
> --
> 
>  * New path module will ONLY support one path sep! There is NO reason
> to support more than one. When we support more than one path sep we
> help to propagate multiplicity.We should only support the slash and
> NOT the backslash across ALL OS's since the slash is more widely
> accepted. If an OS does not have the capability to support only the
> slash then that OS is not worthy of a Python builtin module. The users
> of such OS will be responsible for managing their OWN os_legacy.path
> module. We are moving forward. Those who wish to wallow in the past
> will be left behind.
> 
>  * Introduce a new method named "partition" which (along with string
> splitting methods) will replace the six methods "basename", "dirname",
> "split", "splitdrive", "splitunc", "splittext". The method will return
> a tuple of the path split into four parts: (drive, path, filename,
> extension). This is the ONLY splitting method this module needs. All
> other splits can use string methods.
> 
> --
>  Expose of the Warts of current module:
> --
> 
> 
> ~
>  1. Too many methods
> ~
> 
> Follows is a list of what to keep and what to cull:
> 
>  + abspath
>  + altsep
>  - basename --> path.partition[-2]
>  + commonprefix
>  + curdir
>  + defpath
>  + devnull
>  - dirname --> os.path.join(drive,path)
>  + exists
>  + expanduser
>  + expandvars
>  + extsep
>  - genericpath --> should be private!
>  + getatime
>  + getctime
>  + getmtime
>  + getsize
>  + isabs
>  + isdir
>  + isfile
>  + islink
>  + ismount
>  + join
>  - lexists --> duplicate!
>  - normcase --> path = path.lower()
>  - normpath --> should not need this!
>  - os --> should be private!
>  + pardir
>  + pathsep
>  + realpath
>  + relpath
>  + sep
>  - split --> path.rsplit('/', 1)
>  - splitdrive --> path.split(':', 1)
>  - splitext --> path.rsplit('.')
>  - splitunc --> Unix specific!
>  - stat --> should be private!
>  + supports_unicode_filenames --> windows specific!
>  - sys --> should be private!
>  + walk
>  - warnings --> should be private!
> 
> 
> ~
>  2. Poor Name Choices:
> ~
> 
>  * basename --> should be: filename
>  * split --> split what?
>  * splitext --> Wow, informative!
> 
> ~
>  3. Non Public Names Exposed!
> ~
> 
>  * genericpath
>  * os
>  * stat
>  * sys
>  * warnings
> 
> 
> Note: i did not check the Unix version of os.path for this.
> 
> ~
>  4. Duplicated functionality.
> ~
> 
> >>> os.path.lexists.__doc__
> 'Test whether a path exists.  Returns False for broken symbolic links'
> >>> os.path.exists.__doc__
> 'Test whether a path exists.  Returns False for broken symbolic links'
> 
> Should have been one method:
> >>> os.path.exists(path, ignoreSymLnks=False)
> -- 
> http://mail.python.org/mailman/listinfo/python-list
> 

-- 
Michael Poeltl
Computational Materials Physics  voice: +43-1-4277-51409
Univ. Wien, Sensengasse 8/12 fax:   +43-1-4277-9514 (or 9513) 
A-1090 Wien, AUSTRIA   cmp.mpi.univie.ac.at 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: os.path needs immediate attention!

[Steven D'Aprano]

Andrew Berg wrote:

> os.path.exists(path, ignoreSymLnks=False)
> I actually agree with you on these, which I suppose is interesting.


Guido has a rule of thumb: "No constant arguments". Or another way to put
it: if a function takes an argument which is nearly always a constant
(usually, but not always, a flag) then it is usually better off as two
functions.

Especially if the implementation looks like this:

def get_thing(argument, flag):
if flag:
return one_thing(argument)
else:
return another_thing(argument)


Argument flags which do nothing but change the behaviour of the function
from Mode 1 to Mode 2 are an attractive nuisance: they seem like a good
idea, but aren't. Consider it a strong guideline rather than a law, but
it's one I would think very long and hard about before violating.

But having said that, I'm currently writing a library where nearly all the
functions violate the No Constant Argument rule. (The API isn't yet stable,
so I may still change my mind.) Make of that what you will.


-- 
Steven

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

Re: list comprehension to do os.path.split_all ?

[Steven D'Aprano]

Carl Banks wrote:

> It's not even fullproof on Unix.
> 
> '/home//h1122/bin///ghi/'.split('/')
> 
> ['','home','','bin','','','ghi','']


What? No. Absolutely not -- that would be a major bug. Did you actually try
it?

>>> '/home//h1122/bin///ghi/'.split('/')
['', 'home', '', 'h1122', 'bin', '', '', 'ghi', '']

Exactly as expected, and correct.

Now obviously if you intend treating this as a list of path components, you
have to filter out the empty strings, but otherwise works fine.



-- 
Steven

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

Re: PyWart: os.path needs immediate attention!

[Steven D'Aprano]

Teemu Likonen wrote:

> * 2011-07-29T10:22:04-07:00 *  wrote:
> 
>>  * New path module will ONLY support one path sep! There is NO reason
>> to support more than one.
> 
> Pathnames and the separator for pathname components should be abstracted
> away, to a pathname object.

Been there, done that, floundered on the inability of people to work out the
details.

http://www.python.org/dev/peps/pep-0355/



-- 
Steven

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

Function "modes" vs. separate functions (was: PyWart: os.path needs immediate attention!)

[Andrew Berg]

On 2011.07.29 07:50 PM, Steven D'Aprano wrote:
> Especially if the implementation looks like this:
> 
> def get_thing(argument, flag):
> if flag:
> return one_thing(argument)
> else:
> return another_thing(argument)
> 
Well, that would be annoying, but wouldn't it be even more annoying to
do this:
def get_one_thing(arg):
return one_thing(arg)

def get_another_thing(arg):
return another_thing(arg)

> Argument flags which do nothing but change the behaviour of the function
> from Mode 1 to Mode 2 are an attractive nuisance: they seem like a good
> idea, but aren't. Consider it a strong guideline rather than a law, but
> it's one I would think very long and hard about before violating.
Creating separate functions for two thing that do almost the same thing
seem more of a nuisance to me, especially if they share a lot of code
that isn't easily separated into other functions.

-- 
CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
PGP/GPG Public Key ID: 0xF88E034060A78FCB
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is xrange?

[Steven D'Aprano]

Billy Mays wrote:

> Is xrange not a generator?  I know it doesn't return a tuple or list, so
> what exactly is it?  

xrange pre-dates generators by approximately forever. It returns a
special "xrange object", which generates values suitable for use in
for-loops using the old __getitem__ protocol.

You can consider xrange to be implemented something vaguely like this:

class My_xrange:
def __init__(self, start, end=None, step=1):
if end is None:
end = start
start = 0
self.start = start
self.end = end
self.step = step
def __getitem__(self, index):
if self.step != 1:
raise NotImplementedError('too lazy to support step values')
start, end = self.start, self.end
if start <= index < end:
return start + index
raise IndexError('out of range')



> Y doesn't ever complete, but x does. 
> 
> x = (i for i in range(10))

That is better written as iter(range(10)).


> y = xrange(10)

Y doesn't complete because xrange objects are restartable. The for-loop ends
up using the original iteration protocol:

i = y[0]
i = y[1]
i = y[2]
...

until IndexError is raised. You break after calling y[0], but the next loop
starts at y[0] again, and so you never progress beyond the first item in
the xrange object.


-- 
Steven

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

Re: Function "modes" vs. separate functions

[Ben Finney]

Andrew Berg  writes:

> On 2011.07.29 07:50 PM, Steven D'Aprano wrote:
> > Especially if the implementation looks like this:
> > 
> > def get_thing(argument, flag):
> > if flag:
> > return one_thing(argument)
> > else:
> > return another_thing(argument)
> > 
> Well, that would be annoying, but wouldn't it be even more annoying to
> do this:
> def get_one_thing(arg):
>   return one_thing(arg)
>
> def get_another_thing(arg):
>   return another_thing(arg)

Yes, of course it would be; and even more pointless.

The right thing to do is to call ‘one_thing(argument)’ or
‘another_thing(argument)’ directly.

The greater point is that, since the flag simply switches between
different “things” to do, then that's better communicated in code by
calling differently-named functions that each do one thing.

> Creating separate functions for two thing that do almost the same
> thing seem more of a nuisance to me, especially if they share a lot of
> code that isn't easily separated into other functions.

If they share a lot of code, either it *is* separable to common
functions (in which case, implement it that way), or the “same thing”
code is sufficiently complex that it's better to show it explicitly.

But this is all getting rather generic and abstract. What specific
real-world examples do you have in mind?

-- 
 \  “It is clear that thought is not free if the profession of |
  `\   certain opinions makes it impossible to earn a living.” |
_o__)  —Bertrand Russell, _Free Thought and Official Propaganda_, 1928 |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Function "modes" vs. separate functions (was: PyWart: os.path needs immediate attention!)

[Rustom Mody]

Ben Finney said:
> But this is all getting rather generic and abstract. What specific
> real-world examples do you have in mind?

regex match vs regex search?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Function "modes" vs. separate functions

[Andrew Berg]

On 2011.07.29 08:57 PM, Ben Finney wrote:
> If they share a lot of code, either it *is* separable to common
> functions (in which case, implement it that way), or the “same thing”
> code is sufficiently complex that it's better to show it explicitly.
> 
> But this is all getting rather generic and abstract. What specific
> real-world examples do you have in mind?
I can't come up with any off the top of my head. I was thinking of a
general rule anyway; ultimately one decides (or at least should) how to
write code on a case-by-case basis.

-- 
CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
PGP/GPG Public Key ID: 0xF88E034060A78FCB
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: NoneType and new instances

[Gregory Ewing]

Steven D'Aprano wrote:


As for True and False, bool has to be able to return them, because the whole
purpose of exposing bool is so people can call it: if bool(some_value) was
an error, that would defeat the purpose of having bool!


Bool is different, because it doubles as a function for
coercing things to bool. There's no corresponding concept
of coercing something to None, or Ellipsis, etc.

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

Re: Function "modes" vs. separate functions

[Ben Finney]

Rustom Mody  writes:

> Ben Finney said:
> > But this is all getting rather generic and abstract. What specific
> > real-world examples do you have in mind?
>
> regex match vs regex search?

That's not showing a real-world example. Where is the code which is
prone to “lots of shared code but can't refactor it to a common
function”?

-- 
 \“I fly Air Bizarre. You buy a combination one-way round-trip |
  `\ticket. Leave any Monday, and they bring you back the previous |
_o__) Friday. That way you still have the weekend.” —Steven Wright |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

What's in a name?

[Andrew Berg]

I know I really shouldn't be spending too much time and effort on a
name, but for some reason, it's really bothering me that I can't come up
with good names for the projects I'm working on.

The first (and main) project is a module that provides a class for
holding information related to audio/video encoding/muxing and methods
that encode/mux based on that info. The aim is to provide a backend for
encoding/muxing programs. Essentially, one using the module can write a
program that is essentially an interface without worrying about writing
any wrappers around encoding/muxing programs or logic to manipulate
related data.

The other two are programs that use the module. One is a CLI program and
the other is a PyQt GUI program.

I came up with abstract names (see below) that I don't really like
(because they're so abstract). I also came up with another name for the
module that's okay: Maven (Module for Audio and Video ENcoding).

In case you want to see the code (not complete by a long shot, and they
need to be refactored):
Module -
http://elucidation.hg.sourceforge.net/hgweb/elucidation/elucidation/file/f8da0b15ecca/elucidation.py
CLI app -
http://disillusion-cli.hg.sourceforge.net/hgweb/disillusion-cli/disillusion-cli/file/947d230dbfc3/disillusion.py
I have no code written for the GUI app yet.

Any ideas?
-- 
CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
PGP/GPG Public Key ID: 0xF88E034060A78FCB
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What's in a name?

[harrismh777]

Andrew Berg wrote:

The first (and main) project is a module that provides a class for
holding information related to audio/video encoding/muxing and methods
that encode/mux based on that info.




Any ideas?


Multiplexing Audio Video Encoder

MuXaven




--
m harris

FSF  ...free as in freedom/
http://webpages.charter.net/harrismh777/gnulinux/gnulinux.htm
--
http://mail.python.org/mailman/listinfo/python-list

Re: What's in a name?

[Billy Mays]

On 7/29/2011 11:25 PM, Andrew Berg wrote:

In case you want to see the code (not complete by a long shot, and they
need to be refactored):
Module -
http://elucidation.hg.sourceforge.net/hgweb/elucidation/elucidation/file/f8da0b15ecca/elucidation.py
CLI app -
http://disillusion-cli.hg.sourceforge.net/hgweb/disillusion-cli/disillusion-cli/file/947d230dbfc3/disillusion.py
I have no code written for the GUI app yet.

Any ideas?


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