Re: Low level file descriptors and high-level Python files
In a message of Tue, 01 Sep 2015 22:19:15 -, Grant Edwards writes: >On 2015-09-01, Laura Creighton wrote: > >> Don't go around closing things you don't know are open. They >> could be some other processes' thing. > >I don't understand. Closing a file descriptor that isn't open is >harmless, isn't it? Closing one that _is_ open only affects the >current process. If other processes had the same fd open, it's still >open for them. > >-- >Grant Edwards grant.b.edwardsYow! FUN is never having to > at say you're SUSHI!! > gmail.com This is me being tired and not saying things properly. What I meant was don't go around closing mkstemp files thinking you can reopen them later, because in between the time you use mkstemp to make the file and you open it up again later somebody else may have replaced that file. Including some other program running mkstemp which was desparate to make the exact same filename you did. But that's not what I said ... so thank you. Laura -- https://mail.python.org/mailman/listinfo/python-list
Re: execute commands as su on remote server
Op 18-08-15 om 04:57 schreef harirammanohar...@gmail.com: > execute commands as su on remote server > > Postby hariram » Mon Aug 17, 2015 4:02 am > Needed: > I need to execute commands after doing su to other user on remote server(not > sudo which doesn't require password) how i can achieve this using python? > I googled and came to know that its not possible, so just for confirmation > asking again, is it possible ? > > Already Tried: > Tried paramiko that's too not working. What about pexpect: https://pypi.python.org/pypi/pexpect/ It's been a long time since I used it, but it was for something similar. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python is not both an interpreter and a compiler?
In a message of Wed, 02 Sep 2015 10:50:15 +1000, Chris Angelico writes: >And compiled C programs are notoriously hard to distribute. Can you >pick up a Guile binary and carry it to another computer? Do you have >to absolutely perfectly match the libguile version, architecture, >build settings, etc? This is the problem that docker has set out to solve. https://www.docker.com/whatisdocker I think it is pretty neat stuff, myself. Laura -- https://mail.python.org/mailman/listinfo/python-list
Getting the logging level from text representation
I am writing an application that will do the necessary logging. However I want the level of logging to be deciced by a value in a config file. Like the following: loglevel = WARNING But I can't find a function that does this. The reverse is possible with logging.getLevelName. The documentation also states this: Changed in version 3.4: In Python versions earlier than 3.4, this function could also be passed a text level, and would return the corresponding numeric value of the level. This undocumented behaviour was considered a mistake, and was removed in Python 3.4, but reinstated in 3.4.2 due to retain backward compatibility. So what is the supposed correct way to handle this? Preferably one that works when additional levels have been introduced. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Getting the logging level from text representation
Antoon Pardon wrote:
> I am writing an application that will do the necessary logging.
> However I want the level of logging to be deciced by a value
> in a config file. Like the following:
>
> loglevel = WARNING
>
> But I can't find a function that does this.
>
> The reverse is possible with logging.getLevelName. The documentation
> also states this:
>
> Changed in version 3.4: In Python versions earlier than 3.4, this function
> could also be passed a text level, and would return the corresponding
> numeric value of the level. This undocumented behaviour was considered
> a mistake, and was removed in Python 3.4, but reinstated in 3.4.2 due
> to retain backward compatibility.
>
> So what is the supposed correct way to handle this? Preferably one
> that works when additional levels have been introduced.
Why do you want to convert the name into a number? You can use it directly:
>>> import logging
>>> root = logging.getLogger()
>>> root.level
30
>>> root.setLevel("INFO")
>>> root.level
20
>>> root.setLevel("ROCKET")
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.4/logging/__init__.py", line 1236, in setLevel
self.level = _checkLevel(level)
File "/usr/lib/python3.4/logging/__init__.py", line 179, in _checkLevel
raise ValueError("Unknown level: %r" % level)
ValueError: Unknown level: 'ROCKET'
>>> logging.addLevelName(10987654321, "ROCKET")
>>> root.setLevel("ROCKET")
>>> root.level
10987654321
--
https://mail.python.org/mailman/listinfo/python-list
Using enumerate to get line-numbers with itertools grouper?
I'm using grouper() to iterate over a textfile in groups of lines:
def grouper(iterable, n, fillvalue=None):
"Collect data into fixed-length chunks or blocks"
# grouper('ABCDEFG', 3, 'x') --> ABC DEF Gxx
args = [iter(iterable)] * n
return zip_longest(fillvalue=fillvalue, *args)
However, I'd also like to know the line-number that I'm up to, for printing out
in informational or error messages.
Is there a way to use enumerate with grouper to achieve this?
The below won't work, as enumerate will give me the index of the group, rather
than of the lines themselves:
_BATCH_SIZE = 50
with open(args.input_file, 'r') as f:
for line_number, chunk in enumerate(grouper(f, _BATCH_SIZE)):
print(line_number)
I'm thinking I could do something to modify grouper, maybe, but I'm sure
there's an easier way?
--
https://mail.python.org/mailman/listinfo/python-list
packing unpacking depends on order.
>>> a = [1, 2, 3, 4, 5] >>> b = 1 >>> b, a[b] = a[b], b >>> a [1, 2, 1, 4, 5] >>> a = [1, 2, 3, 4, 5] >>> b = 1 >>> a[b], b = b, a[b] >>> a [1, 1, 3, 4, 5] I think I understand how it gets these results but I'm not really happy with them. I think python should give the second result in both cases. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Getting the logging level from text representation
Op 02-09-15 om 11:50 schreef Peter Otten: > Antoon Pardon wrote: > >> I am writing an application that will do the necessary logging. >> However I want the level of logging to be deciced by a value >> in a config file. Like the following: >> >> loglevel = WARNING >> >> But I can't find a function that does this. >> >> The reverse is possible with logging.getLevelName. The documentation >> also states this: >> >> Changed in version 3.4: In Python versions earlier than 3.4, this function >> could also be passed a text level, and would return the corresponding >> numeric value of the level. This undocumented behaviour was considered >> a mistake, and was removed in Python 3.4, but reinstated in 3.4.2 due >> to retain backward compatibility. >> >> So what is the supposed correct way to handle this? Preferably one >> that works when additional levels have been introduced. > Why do you want to convert the name into a number? You can use it directly: Well because that is a recent change and I didn't know about it and I missed it while browsing the documentation. I think this kind of documenation should be part of the proper description and not part of the history. It also doesn't work for everything. Logger.isEnabledFor(lvl) expect a number. But for the moment it serves my needs, so thanks for pointing it out. -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Re: packing unpacking depends on order.
That's interesting. I agree with you, I'd prefer the second result in both cases. But makes sense as it evaluates left to right and seems to break up the unpacking into separate statements. Could be useful if you want to hold the results of a generator in sequence, can call the same function multiple times and unpack as above. On Wed, Sep 2, 2015 at 11:07 AM Antoon Pardon wrote: > > >>> a = [1, 2, 3, 4, 5] > >>> b = 1 > >>> b, a[b] = a[b], b > >>> a > [1, 2, 1, 4, 5] > >>> a = [1, 2, 3, 4, 5] > >>> b = 1 > >>> a[b], b = b, a[b] > >>> a > [1, 1, 3, 4, 5] > > I think I understand how it gets these results > but I'm not really happy with them. I think python > should give the second result in both cases. > > -- > Antoon Pardon > > -- > https://mail.python.org/mailman/listinfo/python-list > -- - Nick -- https://mail.python.org/mailman/listinfo/python-list
Re: Using enumerate to get line-numbers with itertools grouper?
Victor Hooi wrote:
> I'm using grouper() to iterate over a textfile in groups of lines:
>
> def grouper(iterable, n, fillvalue=None):
> "Collect data into fixed-length chunks or blocks"
> # grouper('ABCDEFG', 3, 'x') --> ABC DEF Gxx
> args = [iter(iterable)] * n
> return zip_longest(fillvalue=fillvalue, *args)
>
> However, I'd also like to know the line-number that I'm up to, for
> printing out in informational or error messages.
>
> Is there a way to use enumerate with grouper to achieve this?
>
> The below won't work, as enumerate will give me the index of the group,
> rather than of the lines themselves:
>
> _BATCH_SIZE = 50
>
> with open(args.input_file, 'r') as f:
> for line_number, chunk in enumerate(grouper(f, _BATCH_SIZE)):
> print(line_number)
>
> I'm thinking I could do something to modify grouper, maybe, but I'm sure
> there's an easier way?
print(line_number * _BATCH_SIZE)
Eureka ;)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Getting the logging level from text representation
In a message of Wed, 02 Sep 2015 12:14:44 +0200, Antoon Pardon writes: See: https://docs.python.org/3.5/library/logging.html#levels you can just use 30 everywhere for warning, and that is what Logger.getEffectiveLevel() will tell you even if you initialised it with the text form. Laura -- https://mail.python.org/mailman/listinfo/python-list
for loop over function that returns a tuple?
I have a function which is meant to return a tuple:
def get_metrics(server_status_json, metrics_to_extract, line_number):
return ((timestamp, "serverstatus", values, tags))
I also have:
def create_point(timestamp, metric_name, values, tags):
return {
"measurement": _MEASUREMENT_PREFIX + metric_name,
"tags": tags,
"time": timestamp,
"fields": values
}
I am calling get_metric in a for loop like so:
for metric_data in get_metrics(server_status_json, mmapv1_metrics,
line_number):
json_points.append(create_point(*metric_data))
I was hoping to use tuple unpacking to pass metric_data straight from
get_metrics through to create_point.
However, in this case, metric_data only contains timestamp.
I suppose I could assign multiple variables like, and pass them through:
for timestamp, metric_name, value, tags in get_metrics(server_status_json,
common_metrics, line_number):
However, that seems unnecessarily verbose, and I'm sure there's a simple way to
do this with tuple unpacking?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Using enumerate to get line-numbers with itertools grouper?
Hi Peter,
Hmm, are you sure that will work?
The indexes returned by enumerate will start from zero.
Also, I've realised line_number is a bit of a misnomer here - it's actually the
index for the chunks that grouper() is returning.
So say I had a 10-line textfile, and I was using a _BATCH_SIZE of 50.
If I do:
print(line_number * _BATCH_SIZE)
I'd just get (0 * 50) = 0 printed out 10 times.
Even if I add one:
print((line_number + 1) * _BATCH_SIZE)
I will just get 50 printed out 10 times.
My understanding is that the file handle f is being passed to grouper, which is
then passing another iterable to enumerate - I'm just not sure of the best way
to get the line numbers from the original iterable f, and pass this through the
chain?
On Wednesday, 2 September 2015 20:37:01 UTC+10, Peter Otten wrote:
> Victor Hooi wrote:
>
> > I'm using grouper() to iterate over a textfile in groups of lines:
> >
> > def grouper(iterable, n, fillvalue=None):
> > "Collect data into fixed-length chunks or blocks"
> > # grouper('ABCDEFG', 3, 'x') --> ABC DEF Gxx
> > args = [iter(iterable)] * n
> > return zip_longest(fillvalue=fillvalue, *args)
> >
> > However, I'd also like to know the line-number that I'm up to, for
> > printing out in informational or error messages.
> >
> > Is there a way to use enumerate with grouper to achieve this?
> >
> > The below won't work, as enumerate will give me the index of the group,
> > rather than of the lines themselves:
> >
> > _BATCH_SIZE = 50
> >
> > with open(args.input_file, 'r') as f:
> > for line_number, chunk in enumerate(grouper(f, _BATCH_SIZE)):
> > print(line_number)
> >
> > I'm thinking I could do something to modify grouper, maybe, but I'm sure
> > there's an easier way?
>
> print(line_number * _BATCH_SIZE)
>
> Eureka ;)
--
https://mail.python.org/mailman/listinfo/python-list
Re: for loop over function that returns a tuple?
Victor Hooi writes: > I have a function which is meant to return a tuple: > > def get_metrics(server_status_json, metrics_to_extract, line_number): > > return ((timestamp, "serverstatus", values, tags)) That returns a single tuple of four values. The double parentheses are redundant. > I also have: > > def create_point(timestamp, metric_name, values, tags): That can take the four values in the tuple returned by get_metrics, ok. > I am calling get_metric in a for loop like so: > > for metric_data in get_metrics(server_status_json, mmapv1_metrics, > line_number): > json_points.append(create_point(*metric_data)) That sets metric_data to each of the four values in the one tuple in turn. You seem to want just: json_points.append(create_point(*get_metrics(...))) > I was hoping to use tuple unpacking to pass metric_data straight from > get_metrics through to create_point. That should be cool. It's the loop that's a little bit too much. (If you want get_metrics to return a singleton tuple containing the four-tuple, you need an extra comma in there: (x) is just x; (x,) is a tuple containing x. -- https://mail.python.org/mailman/listinfo/python-list
Re: packing unpacking depends on order.
On Wed, 2 Sep 2015 08:01 pm, Antoon Pardon wrote: > a = [1, 2, 3, 4, 5] b = 1 b, a[b] = a[b], b a > [1, 2, 1, 4, 5] Equivalent to: temp1 = a[b] # a[1] == 2 temp2 = b # 1 b = temp1 # b = 2 a[b] = temp2 # a[2] = 1 Or using a queue (FIFO) rather than temp variables: push a[b] push b b = pop a[b] = pop which seems sensible to me. The right hand side of the assignment is evaluated left-to-right, and then the assignments are made, from left-to-right. Which I believe matches the documented order. a = [1, 2, 3, 4, 5] b = 1 a[b], b = b, a[b] a > [1, 1, 3, 4, 5] Likewise: temp1 = b # 1 temp2 = a[b] # a[1] == 2 a[b] = temp1 # a[1] = 1 b = temp2 # b = 2 > I think I understand how it gets these results > but I'm not really happy with them. I think python > should give the second result in both cases. Apart from breaking backwards compatibility, how would you implement such a thing? A simple left-to-right assignment rule is easy to implement and easy to understand even when the targets depend on each other. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: packing unpacking depends on order.
On Wed, Sep 2, 2015 at 10:26 PM, Steven D'Aprano wrote: >> I think I understand how it gets these results >> but I'm not really happy with them. I think python >> should give the second result in both cases. > > Apart from breaking backwards compatibility, how would you implement such a > thing? A simple left-to-right assignment rule is easy to implement and easy > to understand even when the targets depend on each other. I don't think this is really a question of implementation - it's a design question of "should". The current behaviour is reasonably sane. But if you're confused by it, there's a simple solution: Don't reference the same "thing" more than once on the LHS. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Using enumerate to get line-numbers with itertools grouper?
Victor Hooi wrote:
> Hi Peter,
>
> Hmm, are you sure that will work?
If you want the starting line for the batch, yes:
$ cat tmp.txt
alpha (line #1)
beta (line #2)
gamma (line #3)
delta (line #4)
epsilon (line #5)
zeta (line #6)
eta (line #7)
theta (line #8)
iota (line #9)
kappa (line #10)
$ cat grouper_demo.py
from itertools import zip_longest
def grouper(iterable, n, fillvalue=None):
args = [iter(iterable)] * n
return zip_longest(fillvalue=fillvalue, *args)
_BATCH_SIZE = 3
with open("tmp.txt", 'r') as f:
for index, chunk in enumerate(grouper(f, _BATCH_SIZE)):
print("batch starting at line", index * _BATCH_SIZE + 1)
print(chunk)
$ python3 grouper_demo.py
batch starting at line 1
('alpha (line #1)\n', 'beta (line #2)\n', 'gamma (line #3)\n')
batch starting at line 4
('delta (line #4)\n', 'epsilon (line #5)\n', 'zeta (line #6)\n')
batch starting at line 7
('eta (line #7)\n', 'theta (line #8)\n', 'iota (line #9)\n')
batch starting at line 10
('kappa (line #10)\n', None, None)
> The indexes returned by enumerate will start from zero.
>
> Also, I've realised line_number is a bit of a misnomer here - it's
> actually the index for the chunks that grouper() is returning.
>
> So say I had a 10-line textfile, and I was using a _BATCH_SIZE of 50.
>
> If I do:
>
> print(line_number * _BATCH_SIZE)
>
> I'd just get (0 * 50) = 0 printed out 10 times.
>
> Even if I add one:
>
> print((line_number + 1) * _BATCH_SIZE)
>
> I will just get 50 printed out 10 times.
So you are trying to solve a slightly different problem. You can attack that
by moving the enumerate() call:
$ cat grouper_demo2.py
from itertools import zip_longest
def grouper(iterable, n, fillvalue=None):
args = [iter(iterable)] * n
return zip_longest(fillvalue=fillvalue, *args)
_BATCH_SIZE = 3
with open("tmp.txt", 'r') as f:
for chunk in grouper(
enumerate(f, 1), _BATCH_SIZE, fillvalue=(None, None)):
print("--- batch ---")
for index, line in chunk:
if index is None:
break
print(index, line, end="")
print()
$ python3 grouper_demo2.py
--- batch ---
1 alpha (line #1)
2 beta (line #2)
3 gamma (line #3)
--- batch ---
4 delta (line #4)
5 epsilon (line #5)
6 zeta (line #6)
--- batch ---
7 eta (line #7)
8 theta (line #8)
9 iota (line #9)
--- batch ---
10 kappa (line #10)
$
--
https://mail.python.org/mailman/listinfo/python-list
Re: packing unpacking depends on order.
Op 02-09-15 om 14:45 schreef Chris Angelico: > On Wed, Sep 2, 2015 at 10:26 PM, Steven D'Aprano wrote: >>> I think I understand how it gets these results >>> but I'm not really happy with them. I think python >>> should give the second result in both cases. >> Apart from breaking backwards compatibility, how would you implement such a >> thing? A simple left-to-right assignment rule is easy to implement and easy >> to understand even when the targets depend on each other. > I don't think this is really a question of implementation - it's a > design question of "should". > > The current behaviour is reasonably sane. Yes it is reasonable sane, I just think the alternative would be saner. > But if you're confused by > it, there's a simple solution: Don't reference the same "thing" more > than once on the LHS. That is rather extreme. It would mean we avoid the following: a[i], b[i] = b[i], a[i] # references i twice on the LHS. a[i], a[j] = a[j], a[i] # references a twice on the LHS. I think a better rule would be: Don't reference and bind the same "thing" on the LHS. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: packing unpacking depends on order.
On Wed, Sep 2, 2015 at 11:59 PM, Antoon Pardon wrote: >> But if you're confused by >> it, there's a simple solution: Don't reference the same "thing" more >> than once on the LHS. > > That is rather extreme. It would mean we avoid the following: > > a[i], b[i] = b[i], a[i] # references i twice on the LHS. > a[i], a[j] = a[j], a[i] # references a twice on the LHS. > > I think a better rule would be: Don't reference and bind > the same "thing" on the LHS. Sure. In any case, it's a programmer's choice; the language has well-defined behaviour even if you don't follow a rule like this, so it's just to help you keep things safe in your own head. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: for loop over function that returns a tuple?
On Wed, 2 Sep 2015 09:49 pm, Victor Hooi wrote:
> I have a function which is meant to return a tuple:
>
> def get_metrics(server_status_json, metrics_to_extract, line_number):
>
> return ((timestamp, "serverstatus", values, tags))
No need for the second pair of parentheses. Technically, no need for any
parens, this will do:
return timestamp, "serverstatus", values, tags
but putting a single pair of parens around the four items is acceptable for
aesthetic reasons.
> I also have:
>
> def create_point(timestamp, metric_name, values, tags):
This function requires four separate values. So you have to either pass four
values, using tuple unpacking, or re-write the function to accept a single
tuple, then unpack it inside the function:
def create_point(items):
timestamp, metric_name, values, tags = items
...
Another possibility is to be clever (perhaps too clever?) and accept either
four arguments or a single tuple of four arguments:
def create_point(*args):
if len(args) == 1:
timestamp, metric_name, values, tags = args[0]
elif len(args) == 4:
timestamp, metric_name, values, tags = args
else:
raise TypeError('too many or too few arguments')
...
But your current solution seems good to me. The create_point function is
self-documenting with four named arguments. You can pass the items
directly:
pt = create_point(this, that, other, another)
or by unpacking a sequence:
pt = create_point(*fourvalues)
Whatever you do, *something* has to unpack the four values. So why not do it
when you call the function?
There is one last possibility. I hesitate to mention it, because it is for
Python 2 only and is not supported in Python 3, but you can also do this:
# Python 2 only
def create_point((timestamp, metric_name, values, tags)):
...
Notice the extra pair of parens? This means that create_point now takes a
single argument, which is automatically unpacked into the four names given.
It is equivalent to the following version:
# Python 3 or Python 2
def create_point(items):
timestamp, metric_name, values, tags = items
...
which I already showed.
> I am calling get_metric in a for loop like so:
>
> for metric_data in get_metrics(server_status_json, mmapv1_metrics,
>line_number):
> json_points.append(create_point(*metric_data))
This version looks fine to me. You're going to have to unpack the data
somewhere, this is as good as place as any other. Or you could write this:
# use nicer names, of course
for a, b, c, d in get_metrics(
server_status_json, mmapv1_metrics, line_number):
json_points.append(create_point(a, b, c, d))
It's all much the same whichever way you do it. I doubt there is any
efficiency difference, pick the version you like to read the most.
> I was hoping to use tuple unpacking to pass metric_data straight from
> get_metrics through to create_point.
>
> However, in this case, metric_data only contains timestamp.
I don't understand this.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: for loop over function that returns a tuple?
Steven D'Aprano writes: > On Wed, 2 Sep 2015 09:49 pm, Victor Hooi wrote: > >> I have a function which is meant to return a tuple: >> >> def get_metrics(server_status_json, metrics_to_extract, line_number): >> >> return ((timestamp, "serverstatus", values, tags)) [- -] >> I am calling get_metric in a for loop like so: >> >> for metric_data in get_metrics(server_status_json, mmapv1_metrics, >>line_number): >> json_points.append(create_point(*metric_data)) [- -] >> I was hoping to use tuple unpacking to pass metric_data straight from >> get_metrics through to create_point. >> >> However, in this case, metric_data only contains timestamp. > > I don't understand this. Like so: for metric_data in (timestamp, "serverstatus", values, tags): foo(*metric_data) Because get_metrics returns a single tuple. If it's really essential to "loop" just once, perhaps wrap the one tuple in a list: for metric_data in [get_metrics(server_status_json, mmapv1_metrics, line_number)]: json_points.append(create_point(*metric_data)) -- https://mail.python.org/mailman/listinfo/python-list
Re: for loop over function that returns a tuple?
On Wed, 2 Sep 2015 09:49 pm, Victor Hooi wrote:
> I have a function which is meant to return a tuple:
>
> def get_metrics(server_status_json, metrics_to_extract, line_number):
>
> return ((timestamp, "serverstatus", values, tags))
>
> I also have:
>
> def create_point(timestamp, metric_name, values, tags):
> return {
> "measurement": _MEASUREMENT_PREFIX + metric_name,
> "tags": tags,
> "time": timestamp,
> "fields": values
> }
>
> I am calling get_metric in a for loop like so:
>
> for metric_data in get_metrics(server_status_json, mmapv1_metrics,
> line_number):
> json_points.append(create_point(*metric_data))
Ah, now I see what's happening!
Sorry for being so dim, I thought that get_metrics returned a list or
sequence of tuples:
[(timestamp, "serverstatus", values, tags),
(timestamp, "serverstatus", values, tags),
...
(timestamp, "serverstatus", values, tags)]
and you were iterating over the list, so that each time you would get a
tuple of four values:
metric_data = (timestamp, "serverstatus", values, tags)
which you can then pass to create_point:
create_point(*metric_data)
So you confused me by saying that metric_data held only the timestamp. But
now I see that I was mistaken, and you are doing this:
for metric_data in get_metrics( ... ): # returns a single tuple
# first time through the loop, metric_data = timestamp;
# second time through the loop, metric_data = "serverstatus"
# third time through the loop, metric_data = values
# final time through the loop, metric_data = tags
Get rid of the loop, and write this:
metric_data = get_metrics(server_status_json, mmapv1_metrics, line_number)
json_points.append(create_point(*metric_data))
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Raymond Hettinger is now featured on ActiveState
I'm not sure how long this has been the case, but Raymond Hettinger is now featured on the ActiveState page with a link direct to his recipes. https://code.activestate.com/ Raymond has long been one of the most productive and popular recipe writers on ActiveState, with many of his recipes being among the most popular, most viewed, and most upvoted on the site. (Some of them have ended up in the standard library as well.) While the quality of recipes at ActiveState varies greatly, beginners and experts alike can learn a lot from Raymond's recipes. https://code.activestate.com/recipes/users/178123/ -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: packing unpacking depends on order.
On 02/09/2015 11:01, Antoon Pardon wrote: a = [1, 2, 3, 4, 5] b = 1 b, a[b] = a[b], b a [1, 2, 1, 4, 5] a = [1, 2, 3, 4, 5] b = 1 a[b], b = b, a[b] a [1, 1, 3, 4, 5] I think I understand how it gets these results but I'm not really happy with them. I think python should give the second result in both cases. You might find this interesting https://www.cyphar.com/blog/post/tuple-unpacking-oddness -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Using enumerate to get line-numbers with itertools grouper?
On 02/09/2015 13:03, Victor Hooi wrote: How many times do people have to be asked before they stop top posting? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: packing unpacking depends on order.
I agree as well. First evaluate the right side, then assign it to the left side at once. On 02.09.2015 12:22, Nick Sarbicki wrote: That's interesting. I agree with you, I'd prefer the second result in both cases. But makes sense as it evaluates left to right and seems to break up the unpacking into separate statements. Could be useful if you want to hold the results of a generator in sequence, can call the same function multiple times and unpack as above. On Wed, Sep 2, 2015 at 11:07 AM Antoon Pardon mailto:antoon.par...@rece.vub.ac.be>> wrote: >>> a = [1, 2, 3, 4, 5] >>> b = 1 >>> b, a[b] = a[b], b >>> a [1, 2, 1, 4, 5] >>> a = [1, 2, 3, 4, 5] >>> b = 1 >>> a[b], b = b, a[b] >>> a [1, 1, 3, 4, 5] I think I understand how it gets these results but I'm not really happy with them. I think python should give the second result in both cases. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list -- - Nick -- https://mail.python.org/mailman/listinfo/python-list
Re: packing unpacking depends on order.
On 9/2/2015 8:26 AM, Steven D'Aprano wrote: On Wed, 2 Sep 2015 08:01 pm, Antoon Pardon wrote: a = [1, 2, 3, 4, 5] b = 1 b, a[b] = a[b], b a [1, 2, 1, 4, 5] Equivalent to: temp1 = a[b] # a[1] == 2 temp2 = b # 1 b = temp1 # b = 2 a[b] = temp2 # a[2] = 1 Or using a queue (FIFO) rather than temp variables: push a[b] push b b = pop a[b] = pop which seems sensible to me. The right hand side of the assignment is evaluated left-to-right, and then the assignments are made, from left-to-right. Which I believe matches the documented order. It does, and '7.2 Assignment statements' ends with this example: """ For instance, the following program prints [0, 2]: x = [0, 1] i = 0 i, x[i] = 1, 2 # i is updated, then x[i] is updated print(x) """ -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: packing unpacking depends on order.
On 9/2/2015 6:01 AM, Antoon Pardon wrote: a = [1, 2, 3, 4, 5] b = 1 b, a[b] = a[b], b a [1, 2, 1, 4, 5] a = [1, 2, 3, 4, 5] b = 1 a[b], b = b, a[b] a [1, 1, 3, 4, 5] I think I understand how it gets these results but I'm not really happy with them. I think python should give the second result in both cases. I do not want the choice taken away from me. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Using enumerate to get line-numbers with itertools grouper?
On 9/2/2015 6:04 AM, Victor Hooi wrote:
I'm using grouper() to iterate over a textfile in groups of lines:
def grouper(iterable, n, fillvalue=None):
"Collect data into fixed-length chunks or blocks"
# grouper('ABCDEFG', 3, 'x') --> ABC DEF Gxx
args = [iter(iterable)] * n
return zip_longest(fillvalue=fillvalue, *args)
However, I'd also like to know the line-number that I'm up to, for printing out
in informational or error messages.
Is there a way to use enumerate with grouper to achieve this?
Without a runnable test example, it is hard to be sure what you want.
However, I believe replacing 'iter(iterable)' with 'enumerate(iterable,
1)', and taking into account that you will get (line_number, line)
tuples instead of lines, will do what you want.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Atomic file save -- code review and comments requested
Howdy,
I have a utility function for performing atomic file saves, and I'd like to
ask for a code review and comments.
I have published this on ActiveState:
https://code.activestate.com/recipes/579097-safely-and-atomically-write-to-a-file/
under an MIT licence. You should read the version there, I discuss the
use-case for the function and include an extensive doc string. Feel free to
comment either here or on the ActiveState site.
Here is the function, minus the docstring (for brevity):
import contextlib
import os
import stat
import tempfile
@contextlib.contextmanager
def atomic_write(filename, text=True, keep=True,
owner=None, group=None, perms=None,
suffix='.bak', prefix='tmp'):
t = (uid, gid, mod) = (owner, group, perms)
if any(x is None for x in t):
info = os.stat(filename)
if uid is None:
uid = info.st_uid
if gid is None:
gid = info.st_gid
if mod is None:
mod = stat.S_IMODE(info.st_mode)
path = os.path.dirname(filename)
fd, tmp = tempfile.mkstemp(
suffix=suffix, prefix=prefix, dir=path, text=text)
try:
with os.fdopen(fd, 'w' if text else 'wb') as f:
yield f
os.rename(tmp, filename)
tmp = None
os.chown(filename, uid, gid)
os.chmod(filename, mod)
finally:
if (tmp is not None) and (not keep):
# Silently delete the temporary file. Ignore any errors.
try:
os.unlink(tmp)
except:
pass
Usage is:
with atomic_write("mydata.txt") as f:
f.write("some data")
# if an error occurs in here, mydata.txt is preserved
# if no error occurs and the with-block exits cleanly,
# mydata.txt is atomically overwritten with the new contents.
The function is written for Python 2.6, but should work on 2.7 as well.
I'm looking for a review of the code, and any general comments. In
particular, have I missed any ways that the function may fail and lose
data?
One question comes to mind -- should I perform a flush and/or sync of the
file before the rename?
Thanks in advance for all constructive comments.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: packing unpacking depends on order.
On Wed, Sep 2, 2015 at 11:42 AM, Terry Reedy wrote: > On 9/2/2015 6:01 AM, Antoon Pardon wrote: >> >> > a = [1, 2, 3, 4, 5] > b = 1 > b, a[b] = a[b], b > a >> >> [1, 2, 1, 4, 5] > > a = [1, 2, 3, 4, 5] > b = 1 > a[b], b = b, a[b] > a >> >> [1, 1, 3, 4, 5] >> >> I think I understand how it gets these results >> but I'm not really happy with them. I think python >> should give the second result in both cases. > > > I do not want the choice taken away from me. I do. I think the former behavior is surprising, and that relying on it would result in confusing, hard-to-read code. If you really want the former, you can easily reproduce it with: temp = a[b] b, a[temp] = temp, b -- https://mail.python.org/mailman/listinfo/python-list
error
Hi,
I have a Python version: Python 2.7.8
I'm runing it on: Fedora release 21
Yesterday I a sent a question:
I'm starting in the Python scripts. I run this script:
import numpy as np
import netCDF4
f = netCDF4.Dataset('uwnd.mon.ltm.nc','r')
f.variables
and I had the message:
netcdf4.py
Traceback (most recent call last):
File "", line 1, in
NameError: name 'netcdf4' is not defined
I had two answers to my question. But I could not understand them. I
don't have expericence with Python. So I downloaded from the Web a code
to calcluate the dew point temperature:
import sys
import numpy as np
# approximation valid for
# 0 degC < T < 60 degC
# 1% < RH < 100%
# 0 degC < Td < 50 degC
# constants
a = 17.271
b = 237.7 # degC
# sys.argv[0] is program name
T=float(sys.argv[1])
RH=float(sys.argv[2])
def dewpoint_approximation(T,RH):
Td = (b * gamma(T,RH)) / (a - gamma(T,RH))
return Td
def gamma(T,RH):
g = (a * T / (b + T)) + np.log(RH/100.0)
return g
Td = dewpoint_approximation(T,RH)
print 'T, RH',T,RH
print 'Td=',Td
Then I run it and I had the message:
p2.py
Traceback (most recent call last):
File "", line 1, in
NameError: name 'p2' is not defined
Like the same error that I had for my first run.
Please, someone can help me. I have a commercial software and I would
like to use Python.
In advance. Thanks,
Conrado
--
https://mail.python.org/mailman/listinfo/python-list
Re: error
>import numpy as np
>
>import netCDF4
>
>f = netCDF4.Dataset('uwnd.mon.ltm.nc','r')
>
>
>f.variables
>
>
>and I had the message:
>
>
>netcdf4.py
>Traceback (most recent call last):
>File "", line 1, in
>NameError: name 'netcdf4' is not defined
You have a file called netcdf4.py
It contains the line:
import netCDF4
python comes along, reads
"import netCDF4"
and goes looking for something named netCDF4 or netCdf4 or netcdf4
or NETDCF4 or NeTcDf4 -- the rules of your file system say that
filenames are case-insensitive ... so all the above are equivalent.
The first place it looks is your home directory. Then it looks in
your PYTHONPATH. Then it looks in the system modules you nicely
loaded for it.
Unfortunately for you, it finds the file netcdf4.py in your home
directory and thinks that is the one you wanted to import.
BANG.
Solution -- stop naming your python files as lower-cased versions
of things you want to import. Renaming it to mynetcdf4.py should
work fine, for instance.
Laura
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
I agree with Skybuck Flying. I am aware if a var is a module function var or a module global var. If I want read or write a global var. Using the keyword global inside each(!) function only to mark the global var writeable in each of the functions is really an over-regulation and very annoying from my point of view. Especially cause a module is a singleton. And globals are only module aware vars. Even Java (type-safe language) need not such things for its static or member vars. I have disliked this already in PHP where one has to do exact the same thing as in Python (and hoped Python does it better, but not). And using an import here is no solution, cause this is something which relates only to the scope and state of a module itself. I therefore would like to see a PEP which allows also writing global module vars inside module functions without the need for explicit setting the keyword "global" in more or less each(!) module function as the first line of code. I hope a lot can/will agree and a new PEP will arise to give this small responsibility back to the developer. Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: error
Where are you running the code from?
The interactive prompt? (E.g. idle, or after you type "python" at the
terminal) or from the terminal? (as in by typing "python p2.py" at the
terminal).
It looks like you're trying to load a file while in the interactive prompt
which won't work that way (it will work if you type "import p2"). When you
should be using "python p2.py" at the terminal.
- Nick
On Wed, 2 Sep 2015 19:20 wrote:
> Hi,
>
>
> I have a Python version: Python 2.7.8
>
> I'm runing it on: Fedora release 21
>
>
> Yesterday I a sent a question:
>
>
> I'm starting in the Python scripts. I run this script:
>
>
> import numpy as np
>
> import netCDF4
>
> f = netCDF4.Dataset('uwnd.mon.ltm.nc','r')
>
>
> f.variables
>
>
> and I had the message:
>
>
> netcdf4.py
> Traceback (most recent call last):
> File "", line 1, in
> NameError: name 'netcdf4' is not defined
>
>
> I had two answers to my question. But I could not understand them. I
> don't have expericence with Python. So I downloaded from the Web a code
> to calcluate the dew point temperature:
>
>
> import sys
> import numpy as np
>
> # approximation valid for
> # 0 degC < T < 60 degC
> # 1% < RH < 100%
> # 0 degC < Td < 50 degC
>
> # constants
> a = 17.271
> b = 237.7 # degC
>
> # sys.argv[0] is program name
> T=float(sys.argv[1])
> RH=float(sys.argv[2])
>
>
> def dewpoint_approximation(T,RH):
>
> Td = (b * gamma(T,RH)) / (a - gamma(T,RH))
>
> return Td
>
>
> def gamma(T,RH):
>
> g = (a * T / (b + T)) + np.log(RH/100.0)
>
> return g
>
>
> Td = dewpoint_approximation(T,RH)
> print 'T, RH',T,RH
> print 'Td=',Td
>
>
> Then I run it and I had the message:
>
> p2.py
>
>
> Traceback (most recent call last):
>File "", line 1, in
> NameError: name 'p2' is not defined
>
>
> Like the same error that I had for my first run.
>
> Please, someone can help me. I have a commercial software and I would
> like to use Python.
>
> In advance. Thanks,
>
> Conrado
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
- Nick
--
https://mail.python.org/mailman/listinfo/python-list
Re: RPI.GPIO Help
Hakugin: Thanks for the correction. Someone elsewhere showed me example code that was very close to yours, with that being the main difference. His gave an error message that red_button was undefined so I moved the code block below the callbacks. After that it ran without producing errors but it was unresponsive. Will try your updated version tomorrow and will keep fiddling with his. Thank you all for warning me about debouncing. The RPi.GPIO library has built in debouncing. You can even adjust the timing of it. Turns out I got one thing right. Someone who knows better than I explained that GPIO.Cleanup() does go at the bottom and outside the def exit_handler() code block like I had it originally. Johannes: Thanks for sharing that. I will take a look at it when I have more time. Must head to the hospital for my treatment in a few minutes. >Are you still calling GPIO.add_event_detect in a while loop? MRAB, apparently yes. Hakugin noticed and update his example code. -- https://mail.python.org/mailman/listinfo/python-list
Re: Atomic file save -- code review and comments requested
On Wed, 2 Sep 2015 19:06 Steven D'Aprano wrote:
Howdy,
I have a utility function for performing atomic file saves, and I'd like to
ask for a code review and comments.
I have published this on ActiveState:
https://code.activestate.com/recipes/579097-safely-and-atomically-write-to-a-file/
under an MIT licence. You should read the version there, I discuss the
use-case for the function and include an extensive doc string. Feel free to
comment either here or on the ActiveState site.
Here is the function, minus the docstring (for brevity):
import contextlib
import os
import stat
import tempfile
@contextlib.contextmanager
def atomic_write(filename, text=True, keep=True,
owner=None, group=None, perms=None,
suffix='.bak', prefix='tmp'):
t = (uid, gid, mod) = (owner, group, perms)
if any(x is None for x in t):
info = os.stat(filename)
if uid is None:
uid = info.st_uid
if gid is None:
gid = info.st_gid
if mod is None:
mod = stat.S_IMODE(info.st_mode)
path = os.path.dirname(filename)
fd, tmp = tempfile.mkstemp(
suffix=suffix, prefix=prefix, dir=path, text=text)
try:
with os.fdopen(fd, 'w' if text else 'wb') as f:
yield f
os.rename(tmp, filename)
tmp = None
os.chown(filename, uid, gid)
os.chmod(filename, mod)
finally:
if (tmp is not None) and (not keep):
# Silently delete the temporary file. Ignore any errors.
try:
os.unlink(tmp)
except:
pass
Usage is:
with atomic_write("mydata.txt") as f:
f.write("some data")
# if an error occurs in here, mydata.txt is preserved
# if no error occurs and the with-block exits cleanly,
# mydata.txt is atomically overwritten with the new contents.
The function is written for Python 2.6, but should work on 2.7 as well.
I'm looking for a review of the code, and any general comments. In
particular, have I missed any ways that the function may fail and lose
data?
One question comes to mind -- should I perform a flush and/or sync of the
file before the rename?
Your with statement will close the file so that shouldn't be necessary.
Not an expert on these things but maybe it makes sense to call chown/chmod
before the rename so that a failure can't result in the replaced file's
permissions being changed.
--
Oscar
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 9/2/2015 11:47 AM, t...@freenet.de wrote: I therefore would like to see a PEP which allows also writing global module vars inside module functions without the need for explicit setting the keyword "global" in more or less each(!) module function as the first line of code. If you're feeling like you need to add global statements to a lot of functions to enable variable sharing/access, it may be codesmell indicating it's time to make a class of things. Emile -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
And to clarify: I have not spoken about sharing constants global (spanning over modules), where the solution provided here using imports is the solution. I have spoken from module vars which are named or are "globals" and its read/write access constraints inside module functions. So even the naming "globals" is something what I dislike, cause it is about module scope. With all other I can agree with Skybuck Flying too: "There is so far nothing else annoying!" (Maybe a missing switch statement). Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On Wed, Sep 2, 2015 at 12:47 PM, wrote: > Using the keyword global inside each(!) function only > to mark the global var writeable in each of the functions > is really an over-regulation and very annoying from my point of view. To me, marking a variable as global in a large number of functions is a code smell that indicates that you're probably overusing globals. Lua is an example of a language that takes the opposite approach: in Lua, every variable is global unless you explicitly mark it as local. Lua is a fine language overall, but that is one of my pet peeves with it as it is all too easy to fall into the trap of neglecting to mark your local variables, and then you end up with too many global variables and a disaster of a code base. > Especially cause a module is a singleton. > And globals are only module aware vars. > Even Java (type-safe language) need not such things for its static or member > vars. Because Java has static typing. It can determine that a variable is static simply by observing that the variable is declared as such in the class and isn't declared in the function. Would you prefer to have to declare all your local variables as "local" just so that you don't have to explicitly declare the (few, I hope) global ones? -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 02.09.2015 20:47, t...@freenet.de wrote: I agree with Skybuck Flying. I am aware if a var is a module function var or a module global var. If I want read or write a global var. Using the keyword global inside each(!) function only to mark the global var writeable in each of the functions is really an over-regulation and very annoying from my point of view. It reflects the collective experience of programmers, computer scientists, and so forth of the last decades. Globals are evil. Stay away from them. Best, Sven -- https://mail.python.org/mailman/listinfo/python-list
dxfwrite spline problem
Hi everyone,
I need to do splines in a dxf file with a script, so I use python dxfwrite : It
seems that it is the best thing that exists... But impossible to be sure.
But I have a problem with : when I run this sample script :
---
#!/usr/bin/python
from dxfwrite import DXFEngine as dxf
spline1 = [(0.0, 0.0), (1.0, 0.0), (2.0, -1.0)]
dwg = dxf.drawing('spline.dxf')
dwg.add(dxf.spline(spline1))
dwg.save()
---
I have this output :
amel@debian:~/job/RR/pl/06$ ./spline.py
Traceback (most recent call last):
File "./spline.py", line 9, in
dwg.save()
File "/usr/local/lib/python2.7/dist-packages/dxfwrite/drawing.py", line 131,
in save
self.save_to_fileobj(fileobj)
File "/usr/local/lib/python2.7/dist-packages/dxfwrite/drawing.py", line 137,
in save_to_fileobj
writetags(fileobj, self.__dxftags__(), self.ENCODING)
File "/usr/local/lib/python2.7/dist-packages/dxfwrite/base.py", line 53, in
writetags
for dxftag in iterdxftags(dxfobj):
File "/usr/local/lib/python2.7/dist-packages/dxfwrite/base.py", line 31, in
iterdxftags
for subtag in iterdxftags(tag):
File "/usr/local/lib/python2.7/dist-packages/dxfwrite/base.py", line 31, in
iterdxftags
for subtag in iterdxftags(tag):
File "/usr/local/lib/python2.7/dist-packages/dxfwrite/base.py", line 31, in
iterdxftags
for subtag in iterdxftags(tag):
File "/usr/local/lib/python2.7/dist-packages/dxfwrite/base.py", line 31, in
iterdxftags
for subtag in iterdxftags(tag):
File "/usr/local/lib/python2.7/dist-packages/dxfwrite/base.py", line 30, in
iterdxftags
for tag in dxfobj.__dxftags__():
File "/usr/local/lib/python2.7/dist-packages/dxfwrite/curves.py", line 157,
in __dxftags__
linetype = self.linetype)
File "/usr/local/lib/python2.7/dist-packages/dxfwrite/entities.py", line 593,
in __init__
self.add_vertices(points)
File "/usr/local/lib/python2.7/dist-packages/dxfwrite/entities.py", line 614,
in add_vertices
for point in points:
File "/usr/local/lib/python2.7/dist-packages/dxfwrite/algebra/cspline.py",
line 98, in _cubic_spline
a = get_a(k, m, delta_t)
File "/usr/local/lib/python2.7/dist-packages/dxfwrite/algebra/cspline.py",
line 76, in get_a
a[n-1] = (h * k[n-2] + k[n-1]) / m[n-1]
ZeroDivisionError: float division by zero
amel@debian:~/job/RR/pl/06$
---
Can somebody please help me ?
Thanks, best regards,
Amka
--
https://mail.python.org/mailman/listinfo/python-list
Re: packing unpacking depends on order.
On 02.09.2015 19:42, Terry Reedy wrote: On 9/2/2015 6:01 AM, Antoon Pardon wrote: a = [1, 2, 3, 4, 5] b = 1 b, a[b] = a[b], b a [1, 2, 1, 4, 5] a = [1, 2, 3, 4, 5] b = 1 a[b], b = b, a[b] a [1, 1, 3, 4, 5] I think I understand how it gets these results but I'm not really happy with them. I think python should give the second result in both cases. I do not want the choice taken away from me. I do as readability and maintainability comes first for me. Btw. you would still be able to perform your choice but more explicitly. However, I fear this would be a very hard break of backwards compatibility. :/ So, what I take away from this thread right now is that one should avoid this type of construction whenever possible as long as Python handles it that way. Best, Sven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 2015-09-02 21:08, Sven R. Kunze wrote: On 02.09.2015 20:47, t...@freenet.de wrote: I agree with Skybuck Flying. I am aware if a var is a module function var or a module global var. If I want read or write a global var. Using the keyword global inside each(!) function only to mark the global var writeable in each of the functions is really an over-regulation and very annoying from my point of view. It reflects the collective experience of programmers, computer scientists, and so forth of the last decades. Globals are evil. Stay away from them. I think it's like that sometimes-misquoted saying "money is the root of all evil". It's "the love of money is the root of all evil". Similarly, it's the love (or misuse or overuse) of globals that's evil, IMHO. -- https://mail.python.org/mailman/listinfo/python-list
Reading \n unescaped from a file
Hi,
I am developing code (Python 3.4) that transforms text data from one
format to another.
As part of the process, I had a set of hard-coded str.replace(...)
functions that I used to clean up the incoming text into the desired
output format, something like this:
dataIn = dataIn.replace('\r', '\\n') # Tidy up linefeeds
dataIn = dataIn.replace('<','<') # Tidy up < character
dataIn = dataIn.replace('>','>') # Tidy up < character
dataIn = dataIn.replace('o','o') # No idea why but lots of these:
convert to 'o' character
dataIn = dataIn.replace('f','f') # .. and these: convert to 'f'
character
dataIn = dataIn.replace('e','e') # .. 'e'
dataIn = dataIn.replace('O','O') # .. 'O'
These statements transform my data correctly, but the list of statements
grows as I test the data so I thought it made sense to store the
replacement mappings in a file, read them into a dict and loop through
that to do the cleaning up, like this:
with open(fileName, 'r+t', encoding='utf-8') as mapFile:
for line in mapFile:
line = line.strip()
try:
if (line) and not line.startswith('#'):
line = line.split('#')[:1][0].strip() # trim any
trailing comments
name, value = line.split('=')
name = name.strip()
self.filterMap[name]=value.strip()
except:
self.logger.error('exception occurred parsing line [{0}] in
file [{1}]'.format(line, fileName))
raise
Elsewhere, I use the following code to do the actual cleaning up:
def filter(self, dataIn):
if dataIn:
for token, replacement in self.filterMap.items():
dataIn = dataIn.replace(token, replacement)
return dataIn
My mapping file contents look like this:
\r = \\n
â = "
< = <
> = >
' = '
F = F
o = o
f = f
e = e
O = O
This all works "as advertised" */except/* for the '\r' => '\\n'
replacement. Debugging the code, I see that my '\r' character is
"escaped" to '\\r' and the '\\n' to 'n' when they are read in from
the file.
I've been googling hard and reading the Python docs, trying to get my
head around character encoding, but I just can't figure out how to get
these bits of code to do what I want.
It seems to me that I need to either:
* change the way I represent '\r' and '\\n' in my mapping file; or
* transform them somehow when I read them in
However, I haven't figured out how to do either of these.
TIA,
--
Rob Hills
Waikiki, Western Australia
--
https://mail.python.org/mailman/listinfo/python-list
Location of an Error Message
Where are the error messages stored? E. g., in which (source code) file is the message "NameError: name 'sdfe' is not defined" stored (except for variable arguments like "sdfe")? I do know that I can throw exceptions for myself, but this question came to my mind in thinking about translating the error messages to improve Python's learning curve for newbies. Additionally, I would be grateful if you would give to me the file name (e. g. in hg.python.org) which is the Interpreter's first piece of source code which deals with the error strings. Many thanks in advance! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 02/09/2015 19:47, t...@freenet.de wrote: I agree with Skybuck Flying. First problem. Using the keyword global inside each(!) function only to mark the global var writeable in each of the functions is really an over-regulation and very annoying from my point of view. Second problem. Any chance of shooting yourself *BEFORE* your code escapes from the laboratory? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Location of an Error Message
On Wed, Sep 2, 2015 at 1:30 PM, wrote: > Where are the error messages stored? E. g., in which (source code) file is > the message "NameError: name 'sdfe' is not defined" stored (except for > variable arguments like "sdfe")? I do know that I can throw exceptions for > myself, but this question came to my mind in thinking about translating the > error messages to improve Python's learning curve for newbies. Grepping the source turns up this: https://hg.python.org/cpython/file/tip/Python/ceval.c#l150 > Additionally, I would be grateful if you would give to me the file name (e. > g. in hg.python.org) which is the Interpreter's first piece of source code > which deals with the error strings. What do you mean by "first"? I don't think the error messages are centralized anywhere. -- https://mail.python.org/mailman/listinfo/python-list
Re: Reading \n unescaped from a file
On Wed, Sep 2, 2015 at 12:03 PM, Rob Hills wrote:
> My mapping file contents look like this:
>
> \r = \\n
> “ = "
Oh, lovely. Code page 1252 when you're expecting UTF-8. Sadly, you're
likely to have to cope with a whole pile of other mojibake if that
happens :(
You have my sympathy.
> < = <
> > = >
> ' = '
> F = F
> o = o
> f = f
> e = e
> O = O
>
> This all works "as advertised" except for the '\r' => '\\n' replacement.
> Debugging the code, I see that my '\r' character is "escaped" to '\\r' and
> the '\\n' to 'n' when they are read in from the file.
Technically, what's happening is that your "\r" is literally a
backslash followed by the letter r; the transformation of backslash
sequences into single characters is part of Python source code
parsing. (Incidentally, why do you want to change a carriage return
into backslash-n? Seems odd.)
Probably the easiest solution would be a simple and naive replace(),
looking for some very specific strings and ignoring everything else.
Easy to do, but potentially confusing down the track if someone tries
something fancy :)
line = line.split('#')[:1][0].strip() # trim any trailing comments
line = line.replace(r"\r", "\r") # repeat this for as many backslash
escapes as you want to handle
Be aware that this, while simple, is NOT capable of handling escaped
backslashes. In Python, "\\r" comes out the same as r"\r", but with
this parser, it would come out the same as "\\\r". But it might be
sufficient for you.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
How to decipher error "Nonetype" Error
I am currently using Jupyter and Pythopn 3.4. I am currently using the following script to parse and convert XML data structures, nested in a CSV - formatted file, convert into a dictionary and then append write it back into the same CSV. I am using the following (I added comments to explain the thought process): https://gist.github.com/ahlusar1989/de2381c1fb77e96ae601 However, when I hit line 40 (referencing the gist), I receive the following error: --- TypeError Traceback (most recent call last) in () 23 # to ensure that the field names in the XML don't match (and override) the 24 # field names already in the dictionary ---> 25 row.update(xml_data) 26 # ensure that the headers have all the right fields 27 headers.update(row.keys()) TypeError: 'NoneType' object is not iterable I can only infer I am passing or converting an empty key or empty row. I welcome feedback. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to decipher error "Nonetype" Error
On Thu, Sep 3, 2015 at 8:15 AM, kbtyo wrote: > However, when I hit line 40 (referencing the gist), I receive the following > error: > > --- > TypeError Traceback (most recent call last) > in () > 23 # to ensure that the field names in the XML don't match (and > override) the > 24 # field names already in the dictionary > ---> 25 row.update(xml_data) > 26 # ensure that the headers have all the right fields > 27 headers.update(row.keys()) > > TypeError: 'NoneType' object is not iterable > > I can only infer I am passing or converting an empty key or empty row. I > welcome feedback. NoneType is the type of the singleton object None. So what this means is that xml_data is None at this point. In your just_xml_data() function, which is what provides xml_data at that point, there are two code branches that matter here: one is the "else: return xml", and the other is the implicit "return None" at the end of the function. If you catch an exception, you print out a message and then allow the function to return None. Is that really your intention? It seems an odd way to do things, but if that is what you want, you'll need to cope with the None return in the main routine. BTW, your gist has a couple of non-comments on lines 48 and 49. If you can make sure that your code is functionally correct, it'll be easier for us to test. (Even more so if you can include a sample input file in the gist, though preferably not a huge one.) At the moment, I'm just eyeballing the code itself, but if someone can actually run the script and reproduce the exact error you're seeing, it makes debugging that much easier. All the best! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
Reflecting the answers I want to add following: Considering class usage is something I thought about but is not the way I want use Python so far. If so, I could stay on oo-scripting languages as well. It is the good idea of Python about modules which are singletons and therefore have already its state (so in some way they are already somehow like classes - except the bad annoying thing with the "global" statement). That said, it is not an overusing of globals cause globals are module vars only. Or have you never written singletons or other classes in e.g Java, C++ with lots of static and class members and methods using this members. With globals in Python are not meant traditional globals (app spanning vars) as already said. Globals in Python are like class-members and statics in OO-languages. Globals are module scope! And therefore it is not the devil or evil problem or code desaster problem or LUA's opposite approach. (local/nonlocal statements I think are needed cause of lambda functionality and is not what I try to discuss here) Hopefully this clarifies a bit more my point of view and you can now agree that using "global" is not only over-regulated but also ugly code. At least the developer should be free to use the "global"-statement (if one really need this?) or not (myself, and hopefully a lot other). Therefore still hoping a new PEP will arise. @Mark Lawrence This response I have not checked. Can you provide arguments or clarify your statement? -- https://mail.python.org/mailman/listinfo/python-list
Re: Reading \n unescaped from a file
On 2015-09-02 03:03, Rob Hills wrote:
Hi,
I am developing code (Python 3.4) that transforms text data from one
format to another.
As part of the process, I had a set of hard-coded str.replace(...)
functions that I used to clean up the incoming text into the desired
output format, something like this:
dataIn = dataIn.replace('\r', '\\n') # Tidy up linefeeds
dataIn = dataIn.replace('<','<') # Tidy up < character
dataIn = dataIn.replace('>','>') # Tidy up < character
dataIn = dataIn.replace('o','o') # No idea why but lots of these:
convert to 'o' character
dataIn = dataIn.replace('f','f') # .. and these: convert to 'f'
character
dataIn = dataIn.replace('e','e') # .. 'e'
dataIn = dataIn.replace('O','O') # .. 'O'
The problem with this approach is that the order of the replacements
matters. For example, changing '<' to '<' and then '&' to '&'
can give a different result to changing '&' to '&' and then '<'
to '<'. If you started with the string '<', then the first order
would go '<' => '<' => '<', whereas the second order
would go '<' => '<' => '<'.
These statements transform my data correctly, but the list of statements
grows as I test the data so I thought it made sense to store the
replacement mappings in a file, read them into a dict and loop through
that to do the cleaning up, like this:
with open(fileName, 'r+t', encoding='utf-8') as mapFile:
for line in mapFile:
line = line.strip()
try:
if (line) and not line.startswith('#'):
line = line.split('#')[:1][0].strip() # trim any
trailing comments
name, value = line.split('=')
name = name.strip()
self.filterMap[name]=value.strip()
except:
self.logger.error('exception occurred parsing line [{0}]
in file [{1}]'.format(line, fileName))
raise
Elsewhere, I use the following code to do the actual cleaning up:
def filter(self, dataIn):
if dataIn:
for token, replacement in self.filterMap.items():
dataIn = dataIn.replace(token, replacement)
return dataIn
My mapping file contents look like this:
\r = \\n
â = "
< = <
> = >
' = '
F = F
o = o
f = f
e = e
O = O
This all works "as advertised" */except/* for the '\r' => '\\n'
replacement. Debugging the code, I see that my '\r' character is
"escaped" to '\\r' and the '\\n' to 'n' when they are read in from
the file.
I've been googling hard and reading the Python docs, trying to get my
head around character encoding, but I just can't figure out how to get
these bits of code to do what I want.
It seems to me that I need to either:
* change the way I represent '\r' and '\\n' in my mapping file; or
* transform them somehow when I read them in
However, I haven't figured out how to do either of these.
Try ast.literal_eval, although you'd need to make it look like a string
literal first:
>>> import ast
>>> line = r'\r = \\n'
>>> print(line)
\r = \\n
>>> old, sep, new = line.partition(' = ')
>>> print(old)
\r
>>> print(new)
\\n
>>> ast.literal_eval('"%s"' % old)
'\r'
>>> ast.literal_eval('"%s"' % new)
'\\n'
>>>
I wouldn't put the &#...; forms into the mappings file (except for the
' one) because they can all be recognised and done in code
('F' is chr(int('070')), for example).
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to decipher error "Nonetype" Error
In <6c0af13a-a07d-4c29-b1fd-dd53768e6...@googlegroups.com> kbtyo writes: > https://gist.github.com/ahlusar1989/de2381c1fb77e96ae601 Are you sure this is the actual code you're running? Lines 48 and 49 are clearly meant to be comments, but they do not begin with a hash sign. -- John Gordon A is for Amy, who fell down the stairs gor...@panix.com B is for Basil, assaulted by bears -- Edward Gorey, "The Gashlycrumb Tinies" -- https://mail.python.org/mailman/listinfo/python-list
Re: Reading \n unescaped from a file
MRAB wrote:
> On 2015-09-02 03:03, Rob Hills wrote:
>> Hi,
>>
>> I am developing code (Python 3.4) that transforms text data from one
>> format to another.
>>
>> As part of the process, I had a set of hard-coded str.replace(...)
>> functions that I used to clean up the incoming text into the desired
>> output format, something like this:
>>
>> dataIn = dataIn.replace('\r', '\\n') # Tidy up linefeeds
>> dataIn = dataIn.replace('<','<') # Tidy up < character
>> dataIn = dataIn.replace('>','>') # Tidy up < character
>> dataIn = dataIn.replace('o','o') # No idea why but lots of
>> these: convert to 'o' character dataIn =
>> dataIn.replace('f','f') # .. and these: convert to 'f'
>> character
>> dataIn = dataIn.replace('e','e') # .. 'e'
>> dataIn = dataIn.replace('O','O') # .. 'O'
>>
> The problem with this approach is that the order of the replacements
> matters. For example, changing '<' to '<' and then '&' to '&'
> can give a different result to changing '&' to '&' and then '<'
> to '<'. If you started with the string '<', then the first order
> would go '<' => '<' => '<', whereas the second order
> would go '<' => '<' => '<'.
>
>> These statements transform my data correctly, but the list of statements
>> grows as I test the data so I thought it made sense to store the
>> replacement mappings in a file, read them into a dict and loop through
>> that to do the cleaning up, like this:
>>
>> with open(fileName, 'r+t', encoding='utf-8') as mapFile:
>> for line in mapFile:
>> line = line.strip()
>> try:
>> if (line) and not line.startswith('#'):
>> line = line.split('#')[:1][0].strip() # trim any
>> trailing comments name, value = line.split('=')
>> name = name.strip()
>> self.filterMap[name]=value.strip()
>> except:
>> self.logger.error('exception occurred parsing line
>> [{0}] in file [{1}]'.format(line, fileName)) raise
>>
>> Elsewhere, I use the following code to do the actual cleaning up:
>>
>> def filter(self, dataIn):
>> if dataIn:
>> for token, replacement in self.filterMap.items():
>> dataIn = dataIn.replace(token, replacement)
>> return dataIn
>>
>>
>> My mapping file contents look like this:
>>
>> \r = \\n
>> â = "
>> < = <
>> > = >
>> ' = '
>> F = F
>> o = o
>> f = f
>> e = e
>> O = O
>>
>> This all works "as advertised" */except/* for the '\r' => '\\n'
>> replacement. Debugging the code, I see that my '\r' character is
>> "escaped" to '\\r' and the '\\n' to 'n' when they are read in from
>> the file.
>>
>> I've been googling hard and reading the Python docs, trying to get my
>> head around character encoding, but I just can't figure out how to get
>> these bits of code to do what I want.
>>
>> It seems to me that I need to either:
>>
>> * change the way I represent '\r' and '\\n' in my mapping file; or
>> * transform them somehow when I read them in
>>
>> However, I haven't figured out how to do either of these.
>>
> Try ast.literal_eval, although you'd need to make it look like a string
> literal first:
>
> >>> import ast
> >>> line = r'\r = \\n'
> >>> print(line)
> \r = \\n
> >>> old, sep, new = line.partition(' = ')
> >>> print(old)
> \r
> >>> print(new)
> \\n
> >>> ast.literal_eval('"%s"' % old)
> '\r'
> >>> ast.literal_eval('"%s"' % new)
> '\\n'
> >>>
There's also codecs.decode():
>>> codecs.decode(r"\r = \\n", "unicode-escape")
'\r = \\n'
> I wouldn't put the &#...; forms into the mappings file (except for the
> ' one) because they can all be recognised and done in code
> ('F' is chr(int('070')), for example).
Or
>>> import html
>>> html.unescape("< ö F")
'< ö F'
Even if you cannot use unescape() directly you might steal the
implementation.
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to decipher error "Nonetype" Error
On Wednesday, September 2, 2015 at 6:29:05 PM UTC-4, Chris Angelico wrote: > On Thu, Sep 3, 2015 at 8:15 AM, kbtyo wrote: > > However, when I hit line 40 (referencing the gist), I receive the following > > error: > > > > --- > > TypeError Traceback (most recent call last) > > in () > > 23 # to ensure that the field names in the XML don't match > > (and override) the > > 24 # field names already in the dictionary > > ---> 25 row.update(xml_data) > > 26 # ensure that the headers have all the right fields > > 27 headers.update(row.keys()) > > > > TypeError: 'NoneType' object is not iterable > > > > I can only infer I am passing or converting an empty key or empty row. I > > welcome feedback. > > NoneType is the type of the singleton object None. So what this means > is that xml_data is None at this point. > > In your just_xml_data() function, which is what provides xml_data at > that point, there are two code branches that matter here: one is the > "else: return xml", and the other is the implicit "return None" at the > end of the function. If you catch an exception, you print out a > message and then allow the function to return None. Is that really > your intention? It seems an odd way to do things, but if that is what > you want, you'll need to cope with the None return in the main > routine. > > BTW, your gist has a couple of non-comments on lines 48 and 49. If you > can make sure that your code is functionally correct, it'll be easier > for us to test. (Even more so if you can include a sample input file > in the gist, though preferably not a huge one.) At the moment, I'm > just eyeballing the code itself, but if someone can actually run the > script and reproduce the exact error you're seeing, it makes debugging > that much easier. > > All the best! > > ChrisA Hi Chris: I made changes to the gist: https://gist.github.com/ahlusar1989/de2381c1fb77e96ae601 Ahh Thanks for catching that. No, I want to skip over the Exception and return the xml_data in the try block. I didn't realize that was the behaviour. I don't want to break the iterative loop. Any advice on how to absolve this? Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On Wed, Sep 2, 2015 at 4:25 PM, wrote: > That said, it is not an overusing of globals cause globals are module vars > only. > Or have you never written singletons or other classes in e.g Java, C++ with > lots of static and class members and methods using this members. I do use lots of static members in Java. 99.99% of them are constants, which if translated to Python globals would not require a global declaration anyway. Class members are not like Python globals. Class members are like Python class attributes. > With globals in Python are not meant traditional globals (app spanning vars) > as already said. > Globals in Python are like class-members and statics in OO-languages. Globals > are module scope! > And therefore it is not the devil or evil problem or code desaster problem > or LUA's opposite approach. > > (local/nonlocal statements I think are needed cause of lambda functionality > and > is not what I try to discuss here) The local statement I was talking about has nothing to do with closures, which I think is what you mean. Within a given function, the compiler needs to have some way of knowing whether a given name is local or global. Currently that's done by the "global" keyword and by checking whether the name is ever assigned within the function. If the "global" keyword is no longer required, then there would have to be some other way for the compiler to distinguish locals from globals. The obvious solution would be to use a "local" keyword instead. That seems to me like it would be a lot more annoying. -- https://mail.python.org/mailman/listinfo/python-list
Re: packing unpacking depends on order.
b, a[b] = a[b], b Nice. If I ever notice that kind of code in our codebase I'll 1) check file history to find out the "author" 2) ask that guy to remove it immediately :-) Vladimir http://itunes.apple.com/us/app/python-code-samples/id1025613117 -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
Hi, my 0.02 I don't personally use globals. And don't like "object oriented" code (my code more inclined toward "functional" style). But sometimes I feel like passing various minor values (like settings) all around app via regular parameters is just too much work. So I use "pseudo-global" object which holds various stuff in its attributes. And I pass that object around my code. But that is just one parameter, not myriads of them. Vladimir http://itunes.apple.com/us/app/python-code-samples/id1025613117 -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 03/09/2015 01:16, Vladimir Ignatov wrote: Hi, my 0.02 I don't personally use globals. And don't like "object oriented" code (my code more inclined toward "functional" style). But sometimes I feel like passing various minor values (like settings) all around app via regular parameters is just too much work. So I use "pseudo-global" object which holds various stuff in its attributes. And I pass that object around my code. But that is just one parameter, not myriads of them. Vladimir http://itunes.apple.com/us/app/python-code-samples/id1025613117 Conceptually something like this https://code.activestate.com/recipes/52308-the-simple-but-handy-collector-of-a-bunch-of-named ? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 02/09/2015 19:47, t...@freenet.de wrote: Even Java (type-safe language) need not such things for its static or member vars. By this comment are you stating that Python is not type safe? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: packing unpacking depends on order.
On Wed, Sep 2, 2015, at 13:26, Sven R. Kunze wrote: > I agree as well. First evaluate the right side, then assign it to the > left side at once. The behavior, if it's *not* "first evaluating the right side", is indistinguishable from it by this test. Assigning the RHS of each case to a separate list yields the same result: >>> a, b = [1, 2, 3, 4, 5], 1 >>> abb = a[b], b >>> bab = b, a[b] >>> b, a[b] = abb >>> a [1, 2, 1, 4, 5] >>> a, b = [1, 2, 3, 4, 5], 1 >>> a[b], b = bab >>> a [1, 1, 3, 4, 5] What's happening is this: >>> abb = a[b], b # 2, 1 >>> bab = b, a[b] # 1, 2 then >>> b, a[b] = abb # b = 2; a[2] = 1 or >>> a[b], b = bab # a[1] = 1; b = 2 The question is what does "assign it to the left side at once" even *mean* in the presence of subscripts? Build up a list of object-subscript pairs (evaluating all the subscripts, including if any may have side effects) before executing any __setitem__? Why is the right side evaluated first? Why not build up this "assignment destination list" first, before evaluating the right side? They wouldn't be distinguished by this test, since the RHS has no side effects, but it'd be easy enough to devise such a test case. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 02/09/2015 23:25, t...@freenet.de wrote: Therefore still hoping a new PEP will arise. @Mark Lawrence This response I have not checked. Can you provide arguments or clarify your statement? The over use of globals is never to be encouraged, which is precisely what this would do. You could try raising this on python-ideas but I suspect you'd be wasting your time, so writing a PEP would almost certainly be a waste of time. Still, if you've got free time go ahead, I won't stop you. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: KB 2670838 - The EVIL UPDATE
On Saturday, 14 March 2015 02:36:01 UTC+10, David H. Lipman wrote: > > > > KB 2670838 - The EVIL UPDATE > > > < snip > > > > > GOODBYE, > > FAILURE TO DO SO PUTS YOUR SYSTEMS AT RISK ! > > > > > > Bye, > > Skybuck. > > I hope you like the taste of shoe leather. > > KB2670838 ==> 2013 ! > > It was not a part of the March '15 Patch tuesday release. > > > -- > Dave > Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk > http://www.pctipp.ch/downloads/dl/35905.asp Maybe so, but this EVIL update continues to wreak havoc. It's completely screwed my development environment 3 times since it was released. The first time, it's evilness was unknown and it took me down for weeks. Complete Windows reinstall didn't even work as it would just be installed again with the same result. The second time was a year later later after a system image restore and the latest was June 2015 after another recovery from the same system image. Because the recovery image doesn't have the update installed, Windows merrily goes ahead and installs it immediately after recovery and takes down Visual Studio. No amount of logging/debugging will help. This update does something that can only be remedied by uninstalling it. I'm onto it now, but the first time it happened I was ready to go all United States Postal Service on Microsoft. ha! -- https://mail.python.org/mailman/listinfo/python-list
Re: packing unpacking depends on order.
On Thu, 3 Sep 2015 04:06 am, Ian Kelly wrote: > On Wed, Sep 2, 2015 at 11:42 AM, Terry Reedy wrote: >> On 9/2/2015 6:01 AM, Antoon Pardon wrote: >>> >>> >> a = [1, 2, 3, 4, 5] >> b = 1 >> b, a[b] = a[b], b >> a >>> >>> [1, 2, 1, 4, 5] [...] > I do. I think the former behavior is surprising, and that relying on > it would result in confusing, hard-to-read code. If you really want > the former, you can easily reproduce it with: Of course it's confusing, but the alternative is even more confusing. b, a[b] = 1, 2 currently has simple, predictable semantics: evaluate the right hand side from left to right, then assign to the left hand side bindings from left to right. The order of assignments does not depend on where the right hand side values come from, or whether a or b already exist. This will work fine: assert "a" not in locals() and "b" not in locals() b, a, a[b] = 1, "CORD".split(), "A" What's the alternative? I asked this question earlier, and got no answer -- apparently at least three people prefer behaviour that they cannot explain how to get the results they want :-) As far as I am concerned, having both of these: b, a[b] = a[b], b a[b], b = b, a[b] result in the same bindings is not only hard to implement, but hard to explain and hard to think about. Try to write an algorithm that gives the result you want, one which supports all the cases including the case where one or both of a and b don't exist prior to the assignments. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On Thu, 3 Sep 2015 04:47 am, t...@freenet.de wrote:
> I agree with Skybuck Flying.
> I am aware if a var is a module function var or a module global var.
Congratulations!
But you're not the Python compiler, which doesn't have your superior insight
and intuition.
Inside a function, how is the compiler supposed to know whether "x = 1"
refers to a global or local?
If you can explain that, then your proposal has the tiniest chance of
success. Without that explanation, it has no hope at all.
[...]
> Especially cause a module is a singleton.
What does that have to do with anything?
> And globals are only module aware vars.
What does that even mean?
> Even Java (type-safe language) need not such things for its static or
> member vars.
Java has different rules for variables -- all variables are statically
defined in Java and known to the compiler, that is not the case with
dynamic languages like Lua, Python, Javascript, PHP.
You can't do this in Java:
name = random.choice(["foo", "bar", "baz"])
exec ("%s = 42" % name+"abc", globals())
globals()[name.upper()] = 999
So tell me, what global variables do you have now?
> I have disliked this already in PHP where one has to do
> exact the same thing as in Python (and hoped Python does it better, but
> not). And using an import here is no solution, cause this is
> something which relates only to the scope and state of a module itself.
Again, I don't understand what your comment even means.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: packing unpacking depends on order.
On Sep 2, 2015 7:51 PM, "Steven D'Aprano" wrote: > > What's the alternative? I asked this question earlier, and got no answer -- > apparently at least three people prefer behaviour that they cannot explain > how to get the results they want :-) > > As far as I am concerned, having both of these: > > b, a[b] = a[b], b > a[b], b = b, a[b] > > result in the same bindings is not only hard to implement, but hard to > explain and hard to think about. Try to write an algorithm that gives the > result you want, I don't think it's really all that difficult. 1) Evaluate the RHS from left to right as is already done, collecting the values to be assigned. 2) Evaluate the LHS from left to right. Note there are only three different types of assignments: assignments to names, assignments to attributes (i.e. using __setattr__), and assignments to items (i.e. using __setitem__). a) For assignments to names, there is nothing to evaluate. b) For assignments to attributes, the expression to the left of the . must be evaluated and stored. c) For assignments to items, the expression before the square brackets and the expression inside the square brackets must be evaluated (probably in that order, although it doesn't much matter as long as it's consistent) and stored. 3) Perform the assignments, again from left to right. There can still be ordering effects, e.g. if you do a, b.c = d, e and b's __setattr__ references a, or if one of the expressions has side effects. The same is also true on the RHS, as it is today. I'm not really concerned with that possibility. > one which supports all the cases including the case where > one or both of a and b don't exist prior to the assignments. That's a red herring. If either a or b don't exist prior to the assignments, then the result of assigning to a[b] *should* be an error. -- https://mail.python.org/mailman/listinfo/python-list
.py to .html generation
Hi friends! Can some one help me with the best module and/or its tutorial, to generate html reports for python scripts? I tried pyreport and sphc; but, i am getting errors. -- https://mail.python.org/mailman/listinfo/python-list
Hello
Hi Python community, I am new to Python and currently taking one online course of computer science and programming using Python. I really like Python because it is simple and clarity but powerful to me. I just joint Python mailing list and i hope to enjoy Python programming discussion with you all. Thank you, phuong phan -- https://mail.python.org/mailman/listinfo/python-list
