Tryton 2.6 released
Hi,
We are happy to announce the 2.6 release of Tryton.
What is Tryton
==
Tryton is a three-tiers high level general purpose application
platform using either PostgreSQL, MySQL or SQLite as database engine.
The core of Tryton (also called Tryton kernel) provides all the
necessary functionalities for a complete application framework: data
persistence, extensive modularity, users management (authentication,
fine grained control for data access, handling of concurrent access of
resources), workflow and report engines, web services and
internationalisation. Thus constituting a complete application platform
which can be used for any relevant purpose.
Website: http://www.tryton.org/
What's new
==
This release brings major changes in the API with the introduction of the
Active Record pattern. But also the graphical user interface was not left
without improvements. And as usual there are many bugfixes, module
improvements and new modules (as announced in the previous release news).
Of course, migration from previous series is fully supported.
Major changes in graphical user interface
-
* Management of model access and create/delete field access.
The client is now aware of the model access which allows the disable buttons
when the user doesn't have access to it.
It is also possible to manage the create/delete event on fields in addition
to read/write.
* Dynamic size limit on the One2Many, Many2Many and Char
It is now possible to limit the size of those fields and the client will
enforce it.
* Remove Please wait box. The popup was annoying because it make the client
lost the focus.
* Paste in editable list view. It is possible to paste from a spreadsheet to
update a set of rows.
Major changes on the server side
* Allow to use Reference field in One2Many Many2Many.
In addition to the Many2One, the reverse field could be a Reference field.
In the future, the link between Move and Shipments will be done like that
instead of having 4 exclusive Many2One fields.
* All kind of buttons have been merge into one simple concept.
* Active Record: This is the result of refactoring work started 2 years ago.
Here are some benefits:
* Reduce the amount of code (about 2.2k lines removed) for example
on_change_with and getter of Function field can be merged.
* Unify access to the value of record if it is stored or not in the
database. It allows to remove of values dictionary on on_change method.
* Remove loop over ids in getter of Function field:
before:
def getter(self, ids, name):
res = {}
for record in self.browse(ids):
res[record.id] = ...
return res
now:
def getter(self, name):
return self
* Rationale the register process of Model (use copy of fields etc.)
* Remove session in wizard. Now the wizard instance is the session.
* Allow to store the views in a XML file instead of the database. This supports
the modification of a view without updating the database. A good speedup for
designing views.
* A new kind of validation has been added the pre_validation. The new
'pre_validation' allows to validate a record without saving it. This is used
by the client to validate lines of a One2Many. With 'pre_validation' it is
possible to provide feedback to the user as soon as possible and before the
record is saved.
Modules
---
account
~~~
* The Trial Balance report displays now the start and end balance in addition
to the debit and credit columns.
* Double-clicking on Balance Sheet opens accounts.
* The Account Chart doesn't show cumulate Debit/Credit by default but only for
the current period.
* The Aged Balance is computed over all fiscalyears.
* The Account Moves have been refactored to include an origin field which
allows to easily link it to the master document. They have two number fields
for draft and posted.
account_stock_continental
~
* Updating cost price create automaticaly a stock accounting move.
purchase
* The purchase manages negative quantities on lines, they will generate Return
Shipments and Credit Note.
stock
~
* A graph has been added showing the evolution in past and future of the stock
level for a product per warehouse.
New modules
---
* stock_lot defines lot of products.
* stock_split adds a wizard to split move.
* account_fr adds French account chart.
* production defines the basics for production management.
* stock_supply_production adds automatic supply mechanisms via production
requests.
Other changes graphical user interface
--
* Constant interpolation has been added to line graph.
* The group could have a readonly state.
* It is possible to define a time
Re: a.index(float('nan')) fails
On 25Oct2012 22:04, Terry Reedy tjre...@udel.edu wrote:
| Containment of nan in collection is tested by is, not ==.
| nan = float('nan')
| nan2 = float('nan')
| nan2 is nan
| False
This argues otherwise, and for use of math.isnan() instead.
I expect you were making the point that another NaN is distinct, but it
didn't seem clear to me.
Cheers,
--
Cameron Simpson c...@zip.com.au
In article 1t8n9hinn...@dns1.nmsu.edu, mcri...@acca.nmsu.edu (Mcrider) writes:
Could one of you physicist-type cyber-riders give a lucid description/
explanation of what some folks loosely refer to as a 'tank-slapper'?
An undamped oscillation of camber thrust, with positive feedback,
applied to the front contact patch? :^)
- Ed Green, ed.gr...@east.sun.com, DoD#0111
--
http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
Dan Loewenherz dloewenh...@gmail.com writes: In this case, profile_id is None when the loop breaks. It would be much more straightforward (and more Pythonic, IMO), to write: client = StrictRedis() while client.spop(profile_ids) as profile_id: print profile_id That is pretty loose, in my opinion. If the loop is supposed to return a string until breaking on None, the break test should explicitly check for None rather than rely on an implicit bool conversion that will also test as false on an empty string. Code that handles strings should do the right thing with the empty string. What you posted relies on an unstated assumption that the strings that come back are never empty. it's a net negative from just doing things the canonical way (with the while / assignment pattern). Yeah, the while/assignment is a bit ugly but it doesn't come up often enough to be a bad problem, imho. -- http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On Fri, Oct 26, 2012 at 5:06 PM, Paul Rubin no.email@nospam.invalid wrote: Dan Loewenherz dloewenh...@gmail.com writes: In this case, profile_id is None when the loop breaks. It would be much more straightforward (and more Pythonic, IMO), to write: client = StrictRedis() while client.spop(profile_ids) as profile_id: print profile_id That is pretty loose, in my opinion. If the loop is supposed to return a string until breaking on None, the break test should explicitly check for None rather than rely on an implicit bool conversion that will also test as false on an empty string. while (client.spop(profile_ids) as profile_id) is not None: print profile_id Why is everyone skirting around C-style assignment expressions as though they're simultaneously anathema and the goal? :) But seriously, this new syntax would probably enhance Python somewhat, but you're going to end up with odd edge cases where it's just as almost-there as current syntax is for what this will solve. Is it worth doing half the job? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: a.index(float('nan')) fails
On 10/25/2012 10:44 PM, Steven D'Aprano wrote:
On Thu, 25 Oct 2012 22:04:52 -0400, Terry Reedy wrote:
It is a consequence of the following, which some people (but not all)
believe is mandated by the IEEE standard.
nan = float('nan')
nan is nan
True
The IEEE 754 standard says nothing about object identity. It only
discusses value equality.
nan == nan
False
IEEE 754 states that all NANs compare unequal to everything, including
NANs with the same bit value. It doesn't make an exception for
comparisons with itself.
I'm not entirely sure why you suggest that there is an argument about
what IEEE 754 says about NANs.
I did not do so.
As far as I can see, the argument is
whether or not language designers should pick and choose which bits of
the standard they want to follow, thus taking a step backwards to the
chaos of numerical computing prior to the IEEE 754 standard.
There has been disagreement about whether the standard mandates that
Python behave the way it does. That is a fact, but I have no interest in
discussing the issue.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: a.index(float('nan')) fails
On 10/25/2012 10:19 PM, MRAB wrote:
On 2012-10-26 03:04, Terry Reedy wrote:
On 10/25/2012 9:46 PM, mambokn...@gmail.com wrote:
a = [float('nan'), 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
a
[nan, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
a.index(float('nan'))
This is a second nan object, and it is not in the list.
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: list.index(x): x not in list
That means, the function .index() cannot detect nan values.
It happens on both Python 2.6 and Python 3.1
Is this a bug? Or I am not using .index() correctly?
It is a consequence of the following, which some people (but not all)
believe is mandated by the IEEE standard.
nan = float('nan')
nan is nan
True
nan == nan
False
nanlist = [nan]
nan in nanlist
True
nanlist.index(nan)
0
.index found the nan.
Containment of nan in collection is tested by is, not ==.
nan2 = float('nan')
nan2 is nan
False
nan2 == nan
False
nan2 in nanlist
False
In summary, .index() looks for an item which is equal to its argument,
but it's a feature of NaN (as defined by the standard) that it doesn't
equal NaN, therefore .index() will never find it.
Except that is *does* find the particular nan object that is in the
collection. So nan in collection and list.index(nan) look for the nan by
identity, not equality. This inconsistency is an intentional decision to
not propagate the insanity of nan != nan to Python collections.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
better way for ' '.join(args) + '\n'?
Hi! General advise when assembling strings is to not concatenate them repeatedly but instead use string's join() function, because it avoids repeated reallocations and is at least as expressive as any alternative. What I have now is a case where I'm assembling lines of text for driving a program with a commandline interface. In this scenario, I'm currently doing this: args = ['foo', 'bar', 'baz'] line = ' '.join(args) + '\n' So, in other words, I'm avoiding all the unnecessary copying, just to make another copy to append the final newline. The only way around this that I found involves creating an intermediate sequence like ['foo', ' ', 'bar', ' ', 'baz', '\n']. This can be done rather cleanly with a generator: def helper(s): for i in s[:-1]: yield i yield ' ' yield s[-1] yield '\n' line = ''.join(tmp(args)) Efficiency-wise, this is satisfactory. However, readability counts and that is where this version fails and that is the reason why I'm writing this message. So, dear fellow Pythonistas, any ideas to improve the original versions efficiency while preserving its expressiveness? Oh, for all those that are tempted to tell me that this is not my bottleneck unless it's called in a very tight loop, you're right. Indeed, the overhead of the communication channel TCP between the two programs is by far dwarving the few microseconds I could save here. I'm still interested in learning new and better solutions though. Cheers! Uli -- http://mail.python.org/mailman/listinfo/python-list
Re: bit count or bit set Python3
On 25-10-12 16:47, Charles Hixson wrote:
In Python3 is there any good way to count the number of on bits in an
integer (after an operation)?
Alternatively, is there any VERY light-weight implementation of a bit
set? I'd prefer to use integers, as I'm probably going to need
thousands of these, if the tests work out. But before I can test, I
need a decent bit counter. (shift, xor, , and | are already present
for integer values, but I also need to count the number of true
items after the logical operation. So if a bitset is the correct
approach, I'll need it to implement those operations, or their
equivalents in terms of union and intersection.)
Or do I need to drop into C for this?
Some time ago I implemented this. Maybe you can use it as inspiration.
def CardSet(iter):
bits = 0L
for el in iter:
bits = bits | (1L el)
return CardSetType(bits)
def CSt(*args):
return CardSet(args)
class CardSetType:
def __init__(self, bits):
self.bits = bits
def __str__(self):
return '{' + ','.join(map(str , self)) + '}'
def __repr__(self):
return 'CSt(' + ','.join(map(str , self)) + ')'
def __eq__(self, term):
return self.bits == term.bits
def __contains__(self, el):
return (1L el) self.bits == 1L el
def __and__(self, term):
return CardSetType(self.bits term.bits)
def __or__(self, term):
return CardSetType(self.bits | term.bits)
def __xor__(self, term):
return CardSetType(self.bits ^ term.bits)
def __sub__(self, term):
return CardSetType(self.bits ~term.bits)
def __le__(self, term):
return self.bits term.bits == self.bits
def __ge__(self, term):
return self.bits | term.bits == self.bits
def __len__(self):
bits = self.bits
full = 1L
shift = 1L
index = 0
mask = []
while full bits:
for i in range(index):
mask[i] = (mask[i] shift) + mask[i]
mask.append(full)
full = (full shift) + full
index = index + 1
shift = 2 * shift
shift = 1
for i in range(index):
bits = ((bits shift) mask[i]) + (bits mask[i])
shift = 2 * shift
return int(bits)
def incl(self, el):
self.bits = self.bits | 1L el
def excl(self, el):
self.bits = self.bits ~(1L el)
def __iter__(self):
return SetIterator(self.bits)
class SetIterator:
def __init__(self, bits):
self.bits = bits
self.offset = 0
def __iter__(self):
return self
def next(self):
if self.bits == 0:
raise StopIteration
else:
while True:
shift = 0
delta = 1
full = 1L
while (self.bits full) == 0:
full = (full delta) + full
shift = delta
delta = delta * 2
if shift == 0:
break
self.offset = self.offset + shift
self.bits = self.bits shift
result = self.offset
self.offset = self.offset + 1
self.bits = self.bits 1
return result
--
http://mail.python.org/mailman/listinfo/python-list
Re: better way for ' '.join(args) + '\n'?
Ulrich Eckhardt wrote: Hi! General advise when assembling strings is to not concatenate them repeatedly but instead use string's join() function, because it avoids repeated reallocations and is at least as expressive as any alternative. What I have now is a case where I'm assembling lines of text for driving a program with a commandline interface. In this scenario, I'm currently doing this: args = ['foo', 'bar', 'baz'] line = ' '.join(args) + '\n' So, in other words, I'm avoiding all the unnecessary copying, just to make another copy to append the final newline. The only way around this that I found involves creating an intermediate sequence like ['foo', ' ', 'bar', ' ', 'baz', '\n']. This can be done rather cleanly with a generator: def helper(s): for i in s[:-1]: yield i yield ' ' yield s[-1] yield '\n' line = ''.join(tmp(args)) Efficiency-wise, this is satisfactory. No, it is not. In a quick timeit test it takes 5 to 10 times as long as the original. Remember that function calls are costly, and that with s[:-1] you are trading the extra string for an extra list. Also, you are doubling the loop implicit in str.join() with the explicit one in your oh-so-efficient generator. However, readability counts and that is where this version fails and that is the reason why I'm writing this message. So, dear fellow Pythonistas, any ideas to improve the original versions efficiency while preserving its expressiveness? Oh, for all those that are tempted to tell me that this is not my bottleneck unless it's called in a very tight loop, you're right. Indeed, the overhead of the communication channel TCP between the two programs is by far dwarving the few microseconds I could save here. I'm still interested in learning new and better solutions though. Even if it were the bottleneck the helper generator approach would still be unhelpful. -- http://mail.python.org/mailman/listinfo/python-list
Re: Quickie - Regexp for a string not at the beginning of the line
Am 26.10.2012 06:45, schrieb Rivka Miller: Thanks everyone, esp this gentleman. Who is this? The solution that worked best for me is just to use a DOT before the string as the one at the beginning of the line did not have any char before it. Which was what I suggested, and where you rudely answered... no one has really helped yet. And obviously... I am a satisfied custormer. ...your perception about yourself and about the role of us Usenet posters seems also not be very sane. Good luck. -- http://mail.python.org/mailman/listinfo/python-list
Re: better way for ' '.join(args) + '\n'?
On Fri, 26 Oct 2012 09:49:50 +0200, Ulrich Eckhardt wrote:
Hi!
General advise when assembling strings is to not concatenate them
repeatedly but instead use string's join() function, because it avoids
repeated reallocations and is at least as expressive as any alternative.
What I have now is a case where I'm assembling lines of text for driving
a program with a commandline interface. In this scenario, I'm currently
doing this:
args = ['foo', 'bar', 'baz']
line = ' '.join(args) + '\n'
So, in other words, I'm avoiding all the unnecessary copying, just to
make another copy to append the final newline.
*shrug*
The difference between ' '.join(sequence) and (' '.join(sequence) + '\n')
is, in Big Oh analysis, insignificant. The first case does O(N)
operations, the second does O(N) + O(N) = 2*O(N) operations, which is
still O(N). In effect, the two differ only by an approximately constant
factor.
If you really care, and you don't mind ending your last line with a
space, just append '\n' to the sequence before calling join.
The only way around this that I found involves creating an intermediate
sequence like ['foo', ' ', 'bar', ' ', 'baz', '\n']. This can be done
rather cleanly with a generator:
def helper(s):
for i in s[:-1]:
yield i
yield ' '
yield s[-1]
yield '\n'
line = ''.join(tmp(args))
Efficiency-wise, this is satisfactory.
Have you actually tested this? I would not be the least surprised if
that's actually less efficient than the (' '.join(seq) + '\n') version.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On Fri, 26 Oct 2012 17:23:12 +1100, Chris Angelico wrote: Why is everyone skirting around C-style assignment expressions as though they're simultaneously anathema and the goal? :) Only if your goal is to introduce an anathema :P -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about long-running web scripts
On Thu, 25 Oct 2012 08:53:11 -0400, David Hutto dwightdhu...@gmail.com wrote: OTOH, Python web scripts can be written as long-running scripts: In this case, what is the added-value of using FastCGI? Why can't the web server simply call the Python script directly, just like CGI? The server should call a the script, or script.sleep() There are also server options to setup when a script is run, other than a cron jo for php. Thanks. Does it mean that Python scripts that rely on either fcgi.py or WSGI really have some endless loop somewhere and will keep running once they're launched by FastCGI? -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about long-running web scripts
On Thu, 25 Oct 2012 14:24:16 +0100, Tim Golden m...@timgolden.me.uk wrote: But actually, I didn't mean one-shot scripts, where the Python interpreter + script must be loaded each time, but rather: If I leave a Python running in an endless loop, why not just use either CGI or some other basic way to call the script instead of FastCGI? In essence, you're describing FastCGI. A Python program (or, indeed, any program) which uses FastCGI runs continuously and waits for the incoming request on a TCP socket (instead of as a sys.stdin stream + env vars immediately after process startup). Thanks for the clarification. Since, unlike PHP, the Python interpreter is not available in a FastCGI-capable version, this explains why the www server must be told which specific Python script to run through FastCGI. The reason I ask for all this, is that I want to understand how things work under the hood before relying on a Python framework to handle the nitty-gritty. -- http://mail.python.org/mailman/listinfo/python-list
Re: Quickie - Regexp for a string not at the beginning of the line
Rivka Miller wrote: I am looking for a regexp for a string not at the beginning of the line. For example, I want to find $hello$ that does not occur at the beginning of the string, ie all $hello$ that exclude ^$hello$. The begging of the string is zero width character. So you could use negative lookahead (?!^). Then the regular expression looks like: /(?!^)\$hello\$/g var str = '$hello$ should not be selected but', str1 = 'not hello but all of the $hello$ and $hello$ ... $hello$ each one '; str.match(/(?!^)\$hello\$/g); //null str1.match(/(?!^)\$hello\$/g); //[$hello$, $hello$, $hello$] -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
Alex, You can read wheezy.web introduction here: http://mindref.blogspot.com/2012/10/wheezy-web-introduction.html Thanks. Andriy Kornatskyy Date: Mon, 15 Oct 2012 18:26:16 -0700 Subject: Re: Fastest web framework From: wuwe...@gmail.com To: python-list@python.org On Oct 15, 11:40 pm, Andriy Kornatskyy andriy.kornats...@live.com wrote: Comments or suggestions are welcome. Performance speed is possibly the least interesting aspect of web frameworks; ease of use readily re-usable 3rd party code figures much higher, IMO. Rather than constantly hammer on about performance, maybe you could take the time to explain any other advantages your framework provides. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about long-running web scripts
On 26/10/2012 10:58, Gilles wrote: On Thu, 25 Oct 2012 14:24:16 +0100, Tim Golden m...@timgolden.me.uk wrote: But actually, I didn't mean one-shot scripts, where the Python interpreter + script must be loaded each time, but rather: If I leave a Python running in an endless loop, why not just use either CGI or some other basic way to call the script instead of FastCGI? In essence, you're describing FastCGI. A Python program (or, indeed, any program) which uses FastCGI runs continuously and waits for the incoming request on a TCP socket (instead of as a sys.stdin stream + env vars immediately after process startup). Thanks for the clarification. Since, unlike PHP, the Python interpreter is not available in a FastCGI-capable version, this explains why the www server must be told which specific Python script to run through FastCGI. I think that this is the distinction you're making: PHP: mod_php (fastcgi mode) runs myscript.php Python: some python fcgi frontend.py runs myscript.py which is, essentially, true, not least because PHP and web apps are pretty much synonymous in many people's minds. Both ways: the only thing PHP does is web; the simplest route to a web app is PHP. Certainly there are Python equivalents (mod_python, mod_wsgi, etc.) which can run in effectively the same way as mod_php, and they could be configured to run an fcgi frontend script, I presume. There's always a certain confusion here because you can often one mechanisms (say, mod_wsgi) to act as another (say legacy one-shot CGI) and because some things are both mechanism and protocol and it's not always easy to tease the two apart. The reason I ask for all this, is that I want to understand how things work under the hood before relying on a Python framework to handle the nitty-gritty. Good scheme. TJG -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about long-running web scripts
On Fri, 26 Oct 2012 12:00:17 +0100, Tim Golden m...@timgolden.me.uk wrote: Certainly there are Python equivalents (mod_python, mod_wsgi, etc.) which can run in effectively the same way as mod_php, and they could be configured to run an fcgi frontend script, I presume. There's always a certain confusion here because you can often one mechanisms (say, mod_wsgi) to act as another (say legacy one-shot CGI) and because some things are both mechanism and protocol and it's not always easy to tease the two apart. Thanks again. -- http://mail.python.org/mailman/listinfo/python-list
Re: Quickie - Regexp for a string not at the beginning of the line
Rivka Miller rivkaumil...@gmail.com writes: Thanks everyone, esp this gentleman. Kind of you to single me out, but it was Janis Papanagnou who first posted the solution that you say works best for you. snip -- Ben. -- http://mail.python.org/mailman/listinfo/python-list
Re: Quickie - Regexp for a string not at the beginning of the line
On 10/25/2012 11:45 PM, Rivka Miller wrote: Thanks everyone, esp this gentleman. The solution that worked best for me is just to use a DOT before the string as the one at the beginning of the line did not have any char before it. That's fine but do you understand that that is not an RE that matches on $hello$ not at the start of a line, it's an RE that matches on any char$hello$ anywhere in the line? There's a difference - if you use a tool that prints the text that matches an RE then the output if the first RE existed would be $hello$ while the output for the second RE would be X$hello$ or Y$hello$ or In some tools you can use /(.)$hello$/ or similar to ignore the first part of the RE (.) and just print the second $hello, but that ability and it's syntax is tool-specific, you still can't say here's an RE that does this, you've got to say here's how to find this text using tool whatever. Ed. I guess, this requires the ability to ignore the CARAT as the beginning of the line. I am a satisfied custormer. No need for returns. :) On Oct 25, 7:11 pm, Ben Bacarisse ben.use...@bsb.me.uk wrote: Rivka Miller rivkaumil...@gmail.com writes: On Oct 25, 2:27 pm, Danny dann90...@gmail.com wrote: Why you just don't give us the string/input, say a line or two, and what you want off of it, so we can tell better what to suggest no one has really helped yet. Really? I was going to reply but then I saw Janis had given you the answer. If it's not the answer, you should just reply saying what it is that's wrong with it. I want to search and modify. Ah. That was missing from the original post. You can't expect people to help with questions that weren't asked! To replace you will usually have to capture the single preceding character. E.g. in sed: sed -e 's/\(.\)$hello\$/\1XXX/' but some RE engines (Perl's, for example) allow you specify zero-width assertions. You could, in Perl, write s/(?=.)\$hello\$/XXX/ without having to capture whatever preceded the target string. But since Perl also has negative zero-width look-behind you can code your request even more directly: s/(?!^)\$hello\$/XXX/ I dont wanna be tied to a specific language etc so I just want a regexp and as many versions as possible. Maybe I should try in emacs and so I am now posting to emacs groups also, although javascript has rich set of regexp facilities. You can't always have a universal solution because different PE implementations have different syntax and semantics, but you should be able to translate Janis's solution of matching *something* before your target into every RE implementation around. examples $hello$ should not be selected but not hello but all of the $hello$ and $hello$ ... $hello$ each one selected I have taken your $s to be literal. That's not 100 obvious since $ is a common (universal?) RE meta-character. snip -- Ben. -- http://mail.python.org/mailman/listinfo/python-list
Re: Quickie - Regexp for a string not at the beginning of the line
On Fri, Oct 26, 2012 at 8:32 AM, Ed Morton mortons...@gmail.com wrote:
On 10/25/2012 11:45 PM, Rivka Miller wrote:
Thanks everyone, esp this gentleman.
The solution that worked best for me is just to use a DOT before the
string as the one at the beginning of the line did not have any char
before it.
That's fine but do you understand that that is not an RE that matches on
$hello$ not at the start of a line, it's an RE that matches on any
char$hello$ anywhere in the line? There's a difference - if you use a tool
that prints the text that matches an RE then the output if the first RE
existed would be $hello$ while the output for the second RE would be
X$hello$ or Y$hello$ or
In some tools you can use /(.)$hello$/ or similar to ignore the first part
of the RE (.) and just print the second $hello, but that ability and
it's syntax is tool-specific, you still can't say here's an RE that does
this, you've got to say here's how to find this text using tool
whatever.
Ed.
I guess, this requires the ability to ignore the CARAT as the beginning of
the line.
I am a satisfied custormer. No need for returns. :)
On Oct 25, 7:11 pm, Ben Bacarisse ben.use...@bsb.me.uk wrote:
Rivka Miller rivkaumil...@gmail.com writes:
On Oct 25, 2:27 pm, Danny dann90...@gmail.com wrote:
Why you just don't give us the string/input, say a line or two, and
what you want off of it, so we can tell better what to suggest
no one has really helped yet.
Really? I was going to reply but then I saw Janis had given you the
answer. If it's not the answer, you should just reply saying what it is
that's wrong with it.
I want to search and modify.
Ah. That was missing from the original post. You can't expect people
to help with questions that weren't asked! To replace you will usually
have to capture the single preceding character. E.g. in sed:
sed -e 's/\(.\)$hello\$/\1XXX/'
but some RE engines (Perl's, for example) allow you specify zero-width
assertions. You could, in Perl, write
s/(?=.)\$hello\$/XXX/
without having to capture whatever preceded the target string. But
since Perl also has negative zero-width look-behind you can code your
request even more directly:
s/(?!^)\$hello\$/XXX/
I dont wanna be tied to a specific language etc so I just want a
regexp and as many versions as possible. Maybe I should try in emacs
and so I am now posting to emacs groups also, although javascript has
rich set of regexp facilities.
You can't always have a universal solution because different PE
implementations have different syntax and semantics, but you should be
able to translate Janis's solution of matching *something* before your
target into every RE implementation around.
examples
$hello$ should not be selected but
not hello but all of the $hello$ and $hello$ ... $hello$ each one
selected
I have taken your $s to be literal. That's not 100 obvious since $ is a
common (universal?) RE meta-character.
snip
--
Ben.
--
http://mail.python.org/mailman/listinfo/python-list
I would use str.find('your string')
It returns -1 if not found, and the index if it finds it.
why use regex for this?
--
Joel Goldstick
--
http://mail.python.org/mailman/listinfo/python-list
Re: bit count or bit set Python3
On 2012-10-25, Ian Kelly ian.g.ke...@gmail.com wrote: On Thu, Oct 25, 2012 at 2:00 PM, Neil Cerutti ne...@norwich.edu wrote: Yes indeed! Python string operations are fast enough and its arithmetic slow enough that I no longer assume I can beat a neat lexicographical solution. Try defeating the following with arithmetic: def is_palindrom(n): s = str(n) return s = s[::-1] Problems like these are fundamentally string problems, not math problems. The question being asked isn't about some essential property of the number, but about its digital representation. Certainly they can be reasoned about mathematically, but the fact remains that the math being done is about the properties of strings. The unexpected part, to me, is that an optimal arithmetic based solution conceptually is more efficient. You need to compute just half the digits of the number and then perform a contant compare operation. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Escaping from the tedium of naive datetime objects.
Yesterday I stumbled upon a nice solution to dealing with naive datetimes vs. localized datetimes, and much of the tedium that issues from that problem. Maybe this is very common knownledge but it wasn't mentioned in anything I've read - it really cleans up some opertaions. http://www.whitemiceconsulting.com/2012/10/setting-course-for-utc.html [constructive] Feedback and other suggestions appreciated. -- Adam Tauno Williams awill...@whitemice.org -- http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On Thursday, October 25, 2012 11:06:01 PM UTC-7, Paul Rubin wrote: Dan Loewenherz dloewenh...@gmail.com writes: In this case, profile_id is None when the loop breaks. It would be much more straightforward (and more Pythonic, IMO), to write: client = StrictRedis() while client.spop(profile_ids) as profile_id: print profile_id That is pretty loose, in my opinion. If the loop is supposed to return a string until breaking on None, the break test should explicitly check for None rather than rely on an implicit bool conversion that will also test as false on an empty string. Code that handles strings should do the right thing with the empty string. What you posted relies on an unstated assumption that the strings that come back are never empty. I think this is a good point. However, I can't think of any situation where I'd want to work with an empty string (in the applications I've worked with, at least). We also don't special case things like this just because x is an empty string. If this while EXPR as VAR thing were to move forward, we shouldn't treat the truth testing any differently than how we already do. IMO we should write our applications with the understanding that '' will return False and work with that. Here's a workaround BTW. Just have that method return a tuple, and do the truth testing yourself if you feel it's necessary. while client.spop(profile_ids) as truthy, profile_id: if not truthy: break print profile_id Here, client.spop returns a tuple, which will always returns true. We then extract the first element and run a truth test on it. The function we use is in charge of determining the truthiness. Dan -- http://mail.python.org/mailman/listinfo/python-list
Re: a.index(float('nan')) fails
On Fri, 26 Oct 2012 03:54:02 -0400, Terry Reedy wrote:
On 10/25/2012 10:44 PM, Steven D'Aprano wrote:
On Thu, 25 Oct 2012 22:04:52 -0400, Terry Reedy wrote:
It is a consequence of the following, which some people (but not all)
believe is mandated by the IEEE standard.
nan = float('nan')
nan is nan
True
The IEEE 754 standard says nothing about object identity. It only
discusses value equality.
nan == nan
False
IEEE 754 states that all NANs compare unequal to everything, including
NANs with the same bit value. It doesn't make an exception for
comparisons with itself.
I'm not entirely sure why you suggest that there is an argument about
what IEEE 754 says about NANs.
I did not do so.
I'm afraid you did. Your quote is shown above, and repeated here:
... some people (but not all) believe is mandated by the IEEE standard
This suggests that there is a disagreement -- an argument -- about what
the IEEE standard mandates about NANs. I don't know why you think this
disagreement exists, or who these some people are. The standard is not
ambiguous, and while it is not readily available at no cost, it is widely
described by many secondary sources.
Every NAN must compare unequal to every float, including itself.
There has been disagreement about whether the standard mandates that
Python behave the way it does. That is a fact, but I have no interest in
discussing the issue.
I'm not entirely sure which behaviour of Python you are referring to
here. If you choose not to reply, of course I can't force you to. It's
your right to make ambiguous statements and then refuse to clarify what
you are talking about.
If you are referring to *identity comparisons*, the IEEE 754 says nothing
about object identity, so it has no bearing on Python's `is` operator.
If you are referring to the fact that `nan != nan` in Python, that is
mandated by the IEEE 754 standard. I can't imagine who maintains that the
standard doesn't mandate that; as I said, the disagreement that I have
seen is whether or not to follow the standard, not on what the standard
says.
If you are referring to something else, I don't know what it is.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On Fri, Oct 26, 2012 at 9:29 AM, Dan Loewenherz dloewenh...@gmail.com wrote: while client.spop(profile_ids) as truthy, profile_id: if not truthy: break print profile_id Here, client.spop returns a tuple, which will always returns true. We then extract the first element and run a truth test on it. The function we use is in charge of determining the truthiness. I don't like the idea of testing the first element. There's a large element of surprise in doing that, I think. I would expect the truth test to be the same with or without the existence of the as clause there. That is, you should be able to remove the as clause and have exactly the same behavior, just without the assignments. So it would need to test the entire tuple. That brings up an interesting additional question in my mind, though. Should the while loop syntax attempt to perform the assignment on the very last test, when the expression is false? I think there is a good argument for doing so, as it will allow additional inspection of the false value, if necessary. In the above, though, if the return value is false (an empty tuple or None) then the assignment would fail during unpacking, raising an exception. -- http://mail.python.org/mailman/listinfo/python-list
Re: bit count or bit set Python3
On Thursday, October 25, 2012 7:56:25 AM UTC-7, Charles Hixson wrote: In Python3 is there any good way to count the number of on bits in an integer (after an operation)? You may want to look at gmpy2[1] and the popcount() function. Alternatively, is there any VERY light-weight implementation of a bit set? I'd prefer to use integers, as I'm probably going to need thousands of these, if the tests work out. But before I can test, I need a decent bit counter. (shift, xor, , and | are already present for integer values, but I also need to count the number of true items after the logical operation. So if a bitset is the correct approach, Whether or not gmpy2 is considered light-weight is debateable. :) I'll need it to implement those operations, or their equivalents in terms of union and intersection.) Or do I need to drop into C for this? [1] http://code.google.com/p/gmpy/ -- Charles Hixson -- http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
Dan Loewenherz dloewenh...@gmail.com writes: We also don't special case things like this just because x is an empty string. If this while EXPR as VAR thing were to move forward, we shouldn't treat the truth testing any differently than how we already do. IMO we should write our applications with the understanding that '' will return False and work with that. We don't already treat the truth testing any particular way because we don't have this construction in the language at the moment. However, it's well-established in Python that converting a string to a bool results in False iff the string is empty. The empty string is a perfectly good string and code that deals with strings should handle the empty string properly, unless it knows the string won't be empty. Basic modularity principles say to avoid putting such knowledge into more of the code than necessary. The conclusion is to not automatically convert the parameter to a bool. However, if the as can be part of an expression as in Chris Angelico's post, Chris's suggestion while (client.spop(profile_ids) as profile_id) is not None: print profile_id looks good to me. while client.spop(profile_ids) as truthy, profile_id: if not truthy: break This is ugly on two levels. First of all, if the .spop() still returns None at the end of the input, the tuple unpacking will fail. Second, the separate test and break defeats the purpose of the while ... as construction. Might as well use the current style of assignment and test inside the loop. -- http://mail.python.org/mailman/listinfo/python-list
Re: a.index(float('nan')) fails
On Fri, 26 Oct 2012 04:00:03 -0400, Terry Reedy wrote: On 10/25/2012 10:19 PM, MRAB wrote: In summary, .index() looks for an item which is equal to its argument, but it's a feature of NaN (as defined by the standard) that it doesn't equal NaN, therefore .index() will never find it. Except that is *does* find the particular nan object that is in the collection. So nan in collection and list.index(nan) look for the nan by identity, not equality. So it does. I made the same mistake as MRAB, thank you for the correction. This inconsistency is an intentional decision to not propagate the insanity of nan != nan to Python collections. That's a value judgement about NANs which is not shared by everyone. Quite frankly, I consider it an ignorant opinion about NANs, despite what Bertrand Meyer thinks. Reflectivity is an important property, but it is not the only important property and it is not even the most important property of numbers. There are far worse problems with floats than the non-reflexivity of NANs. Since it is impossible to have a fixed-size numeric type that satisfies *all* of the properties of real numbers, some properties must be broken. I can only imagine that the reason Meyer, and presumably you, think that the loss of reflexivity is more insane than the other violations of floating point numbers is due to unfamiliarity. (And note that I said *numbers*, not NANs.) Anyone who has used a pocket calculator will be used to floating point calculations being wrong, so much so that most people don't even think about it. They just expect numeric calculations to be off by a little, and don't give it any further thought. But NANs freak them out because they're different. In real life, you are *much* more likely to run into these examples of insanity of floats than to be troubled by NANs: - associativity of addition is lost - distributivity of multiplication is lost - commutativity of addition is lost - not all floats have an inverse e.g. (0.1 + 0.2) + 0.3 != 0.1 + (0.2 + 0.3) 1e6*(1.1 + 2.2) != 1e6*1.1 + 1e6*2.2 1e10 + 0.1 + -1e10 != 1e10 + -1e10 + 0.1 1/(1/49.0) != 49.0 Such violations of the rules of real arithmetic aren't even hard to find. They're everywhere. In practical terms, those sorts of errors are *far* more significant in computational mathematics than the loss of reflexivity. I can't think of the last time I've cared that x is not necessarily equal to x in a floating point calculation, but the types of errors shown above are *constantly* effecting computations and leading to loss of precision or even completely wrong answers. Once NANs were introduced, keeping reflexivity would lead to even worse situations than x != x. It would lead to nonsense identities like log(-1) ==log(-2), hence 1 == 2. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: better way for ' '.join(args) + '\n'?
Hi Ulrich,
is this acceptable?
args = ['foo', 'bar', 'baz']
args.append('\n')
line = ' '.join(args)
Cheers,
Hubert
On 10/26/2012 09:49 AM, Ulrich Eckhardt wrote:
Hi!
General advise when assembling strings is to not concatenate them
repeatedly but instead use string's join() function, because it avoids
repeated reallocations and is at least as expressive as any alternative.
What I have now is a case where I'm assembling lines of text for driving
a program with a commandline interface. In this scenario, I'm currently
doing this:
args = ['foo', 'bar', 'baz']
line = ' '.join(args) + '\n'
So, in other words, I'm avoiding all the unnecessary copying, just to
make another copy to append the final newline.
The only way around this that I found involves creating an intermediate
sequence like ['foo', ' ', 'bar', ' ', 'baz', '\n']. This can be done
rather cleanly with a generator:
def helper(s):
for i in s[:-1]:
yield i
yield ' '
yield s[-1]
yield '\n'
line = ''.join(tmp(args))
Efficiency-wise, this is satisfactory. However, readability counts and
that is where this version fails and that is the reason why I'm writing
this message. So, dear fellow Pythonistas, any ideas to improve the
original versions efficiency while preserving its expressiveness?
Oh, for all those that are tempted to tell me that this is not my
bottleneck unless it's called in a very tight loop, you're right.
Indeed, the overhead of the communication channel TCP between the two
programs is by far dwarving the few microseconds I could save here. I'm
still interested in learning new and better solutions though.
Cheers!
Uli
--
http://mail.python.org/mailman/listinfo/python-list
Re: bit count or bit set Python3
cas...@gmail.com wrote: On Thursday, October 25, 2012 7:56:25 AM UTC-7, Charles Hixson wrote: In Python3 is there any good way to count the number of on bits in an integer (after an operation)? You may want to look at gmpy2[1] and the popcount() function. Alternatively, is there any VERY light-weight implementation of a bit set? I'd prefer to use integers, as I'm probably going to need thousands of these, if the tests work out. But before I can test, I need a decent bit counter. (shift, xor,, and | are already present for integer values, but I also need to count the number of true items after the logical operation. So if a bitset is the correct approach, Whether or not gmpy2 is considered light-weight is debateable. :) I'll need it to implement those operations, or their equivalents in terms of union and intersection.) Or do I need to drop into C for this? [1] http://code.google.com/p/gmpy/ -- Charles Hixson I can see many times when that would be useful, but for this particular case I think that bin(val).count(1) is probably the better solution. The other options that I need are already available directly in integer numbers, and I will be surprised if I need more than a 32-bit set, so integers should be a reasonable approach. It doesn't seem to have the overhead that I feared a string conversion would have (possibly because converting an integer to a bit string is trivial), so I don't think that gmpy would add value to this program. Next I need to decide about weak pointers, and then shelve vs. tokyocabinet. (I sort of don't like shelve, because of its use of pickle, with the attendent security risks. OTOH, the file will be local to the computer, not going over the net, which minimizes that. Still, I may decide to reimplement it using ast.literal_eval, as I'm not intending to store anything that it won't handle. -- http://mail.python.org/mailman/listinfo/python-list
Re: a.index(float('nan')) fails
On 2012-10-26 17:23, Steven D'Aprano wrote: On Fri, 26 Oct 2012 04:00:03 -0400, Terry Reedy wrote: On 10/25/2012 10:19 PM, MRAB wrote: In summary, .index() looks for an item which is equal to its argument, but it's a feature of NaN (as defined by the standard) that it doesn't equal NaN, therefore .index() will never find it. Except that is *does* find the particular nan object that is in the collection. So nan in collection and list.index(nan) look for the nan by identity, not equality. So it does. I made the same mistake as MRAB, thank you for the correction. [snip] Yes, I forgot that Python checks for identity before checking for equality: [float(nan)].index(float(nan)) Traceback (most recent call last): File pyshell#0, line 1, in module [float(nan)].index(float(nan)) ValueError: nan is not in list nan = float(nan) [nan].index(nan) 0 -- http://mail.python.org/mailman/listinfo/python-list
Re: a.index(float('nan')) fails
On Sat, Oct 27, 2012 at 3:23 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: In real life, you are *much* more likely to run into these examples of insanity of floats than to be troubled by NANs: - associativity of addition is lost - distributivity of multiplication is lost - commutativity of addition is lost - not all floats have an inverse e.g. (0.1 + 0.2) + 0.3 != 0.1 + (0.2 + 0.3) 1e6*(1.1 + 2.2) != 1e6*1.1 + 1e6*2.2 1e10 + 0.1 + -1e10 != 1e10 + -1e10 + 0.1 1/(1/49.0) != 49.0 Such violations of the rules of real arithmetic aren't even hard to find. They're everywhere. Actually, as I see it, there's only one principle to take note of: the HMS Pinafore Floating Point Rule... ** Floating point expressions should never be tested for equality ** ** What, never? ** ** Well, hardly ever! ** The problem isn't with the associativity, it's with the equality comparison. Replace x == y with abs(x-y)epsilon for some epsilon and all your statements fulfill people's expectations. (Possibly with the exception of 1e10 + 0.1 + -1e10 as it's going to be hard for an automated algorithm to pick a useful epsilon. But it still works.) Ultimately, it's the old problem of significant digits. Usually it only comes up with measured quantities, but this is ultimately the same issue. Doing calculations to greater precision than the answer warrants is fine, but when you come to compare, you effectively need to round both values off to their actual precisions. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Recommended way to unpack keyword arguments using **kwargs ?
I have been doing the following to keep my class declarations short:
class MyClass(MyOtherClass):
def __init__(self,*args,**kwargs):
self.MyAttr = kwargs.get('Attribute',None) #To get a default
MyOtherClass.__init__(self,*args,**kwargs)
Is there a recommended way to get keyword arguments (or default) when using
** notation?
--
Cheerios,
Jeff Jeffries III
CFO: www.touchmycake.com http://www.willyoubemyfriend.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: Recommended way to unpack keyword arguments using **kwargs ?
On Fri, Oct 26, 2012 at 10:58 AM, Jeff Jeffries
jeff.jeffries@gmail.com wrote:
I have been doing the following to keep my class declarations short:
class MyClass(MyOtherClass):
def __init__(self,*args,**kwargs):
self.MyAttr = kwargs.get('Attribute',None) #To get a default
MyOtherClass.__init__(self,*args,**kwargs)
Is there a recommended way to get keyword arguments (or default) when using
** notation?
It's better form to use .pop() instead of .get(), as if MyClass is
receiving the argument then MyOtherClass is probably not expecting it.
If using Python 3, you can use the keyword-only argument syntax:
def __init__(self, *args, attribute=None, **kwargs):
# Do something with attribute
MyOtherClass.__init__(self, *args, **kwargs)
Either way, you should really only do this when there are a large
number of possible arguments or you don't really know what arguments
to expect. When practical to do so, it is preferable to explicitly
list the arguments so that the method signature can be inspected, e.g.
by the help() command.
--
http://mail.python.org/mailman/listinfo/python-list
Re: a.index(float('nan')) fails
On Sat, 27 Oct 2012 03:45:46 +1100, Chris Angelico wrote: On Sat, Oct 27, 2012 at 3:23 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: In real life, you are *much* more likely to run into these examples of insanity of floats than to be troubled by NANs: - associativity of addition is lost - distributivity of multiplication is lost - commutativity of addition is lost - not all floats have an inverse e.g. (0.1 + 0.2) + 0.3 != 0.1 + (0.2 + 0.3) 1e6*(1.1 + 2.2) != 1e6*1.1 + 1e6*2.2 1e10 + 0.1 + -1e10 != 1e10 + -1e10 + 0.1 1/(1/49.0) != 49.0 Such violations of the rules of real arithmetic aren't even hard to find. They're everywhere. Actually, as I see it, there's only one principle to take note of: the HMS Pinafore Floating Point Rule... ** Floating point expressions should never be tested for equality ** ** What, never? ** ** Well, hardly ever! ** The problem isn't with the associativity, it's with the equality comparison. Replace x == y with abs(x-y)epsilon for some epsilon and all your statements fulfill people's expectations. O RYLY? Would you care to tell us which epsilon they should use? Hint: *whatever* epsilon you pick, there will be cases where that is either stupidly too small, stupidly too large, or one that degenerates to float equality. And you may not be able to tell if you have one of those cases or not. Here's a concrete example for you: What *single* value of epsilon should you pick such that the following two expressions evaluate correctly? sum([1e20, 0.1, -1e20, 0.1]*1000) == 200 sum([1e20, 99.9, -1e20, 0.1]*1000) != 200 The advice never test floats for equality is: (1) pointless without a good way to know what epsilon they should use; (2) sheer superstition since there are cases where testing floats for equality is the right thing to do (although I note you dodged that bullet with hardly ever *wink*); and most importantly (3) missing the point, since the violations of the rules of real-valued mathematics still occur regardless of whether you explicitly test for equality or not. For instance, if you write: result = a + (b + c) some compilers may assume associativity and calculate (a + b) + c instead. But that is not guaranteed to give the same result! (KR allowed C compilers to do that; the subsequent ANSI C standard prohibited re- ordering, but in practice most C compilers provide a switch to allow it.) A real-world example: Python's math.fsum is a high-precision summation with error compensation based on the Kahan summation algorithm. Here's a pseudo-code version: http://en.wikipedia.org/wiki/Kahan_summation_algorithm which includes the steps: t = sum + y; c = (t - sum) - y; A little bit of algebra should tell you that c must equal zero. Unfortunately, in this case algebra is wrong, because floats are not real numbers. c is not necessarily zero. An optimizing compiler, or an optimizing programmer, might very well eliminate those calculations and so inadvertently eliminate the error compensation. And not an equals sign in sight. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: a.index(float('nan')) fails
On 10/26/2012 11:26 AM, Steven D'Aprano wrote:
On Fri, 26 Oct 2012 03:54:02 -0400, Terry Reedy wrote:
On 10/25/2012 10:44 PM, Steven D'Aprano wrote:
On Thu, 25 Oct 2012 22:04:52 -0400, Terry Reedy wrote:
It is a consequence of the following, which some people (but not all)
believe is mandated by the IEEE standard.
nan = float('nan')
nan is nan
True
The IEEE 754 standard says nothing about object identity. It only
discusses value equality.
nan == nan
False
IEEE 754 states that all NANs compare unequal to everything, including
NANs with the same bit value. It doesn't make an exception for
comparisons with itself.
I'm not entirely sure why you suggest that there is an argument about
what IEEE 754 says about NANs.
I did not do so.
I'm afraid you did. Your quote is shown above, and repeated here:
The quote precedes and refers to Python code.
... some people (but not all) believe is mandated by the IEEE standard
This suggests that there is a disagreement -- an argument -- about what
the IEEE standard mandates about NANs.
Disagreement about what Python should do has been expressed on the lists
and even on the tracker. There was one discussion on python-ideas within
the last month, another a year or so ago.
Python does not implement the full IEEE standard with signalling and
non-signalling nans and multiple bit patterns.
When a nan is put in a Python collection, it is in effect treated as if
it were equal to itself.
See the discussion in http://bugs.python.org/issue4296
including I'm not sure that Python should be asked to guarantee
anything more than b == b returning False when b is
a NaN. It wouldn't seem unreasonable to consider
behavior of nans in containers (sets, lists, dicts)
as undefined when it comes to equality and identity
checks.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
[ANN] pypiserver 1.0.0 - minimal private pypi server
Hi, I've just uploaded pypiserver 1.0.0 to the python package index. pypiserver is a minimal PyPI compatible server. It can be used to serve a set of packages and eggs to easy_install or pip. pypiserver is easy to install (i.e. just 'pip install pypiserver'). It doesn't have any external dependencies. http://pypi.python.org/pypi/pypiserver/ should contain enough information to easily get you started running your own PyPI server in a few minutes. The code is available on github: https://github.com/schmir/pypiserver Changes in version 1.0.0 - add passlib and waitress to pypi-server-standalone - upgrade bottle to 0.11.3 - Update scripts/opensuse/pypiserver.init - Refuse to re upload existing file - Add 'console_scripts' section to 'entry_points', so 'pypi-server.exe' will be created on Windows. - paste_app_factory now use the the password_file option to create the app. Without this the package upload was not working. - Add --fallback-url argument to pypi-server script to make it configurable. -- Cheers Ralf -- http://mail.python.org/mailman/listinfo/python-list
Re: a.index(float('nan')) fails
On 10/26/2012 12:23 PM, Steven D'Aprano wrote: On Fri, 26 Oct 2012 04:00:03 -0400, Terry Reedy wrote: This inconsistency is an intentional decision to not propagate the insanity of nan != nan to Python collections. That's a value judgement about NANs which is not shared by everyone. Quite frankly, I consider it an ignorant opinion about NANs, despite what Bertrand Meyer thinks. Reflectivity is an important property, but it is not the only important property and it is not even the most important property of numbers. Reflexivity is one of the definitional properties of the mathematical equality relationship and of equivalence relationships in general. It is not specific to numbers. It is assumed by the concept and definition of sets. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: a.index(float('nan')) fails
On Fri, Oct 26, 2012 at 2:40 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: The problem isn't with the associativity, it's with the equality comparison. Replace x == y with abs(x-y)epsilon for some epsilon and all your statements fulfill people's expectations. O RYLY? Would you care to tell us which epsilon they should use? I would assume some epsilon that bounds the error of their computation. Which one to use would depend on the error propagation their function incurs. That said, I also disagree with the sentiment all your statements fulfill people's expectations. Comparing to be within some epsilon of each other may mean that some things that are the result of mathematically unequal expressions, will be called equal because they are very close to each other by accident. Unless perhaps completely tight bounds on error can be achieved? I've never seen anyone do this, but maybe it's reasonable. Hint: *whatever* epsilon you pick, there will be cases where that is either stupidly too small, stupidly too large, or one that degenerates to float equality. And you may not be able to tell if you have one of those cases or not. Here's a concrete example for you: What *single* value of epsilon should you pick such that the following two expressions evaluate correctly? sum([1e20, 0.1, -1e20, 0.1]*1000) == 200 sum([1e20, 99.9, -1e20, 0.1]*1000) != 200 Some computations have unbounded error, such as computations where catastrophic cancellation can occur. That doesn't mean all computations do. For many computations, you can find a single epsilon that will always return True for things that should be equal, but aren't -- for example, squaring a number does no worse than tripling the relative error, so if you square a number that was accurate to within machine epsilon, and want to compare it to a constant, you can compare with relative epsilon = 3*machine_epsilon. I'm not sure how commonly this occurs in real life, because I'm not a numerical programmer. All I know is that your example is good, but shows a not-universally-applicable problem. It is, however, still pretty applicable and worth noting, so I'm not unhappy you did. For example, how large can the absolute error of the sin function applied to a float be? Answer: as large as 2, and the relative error can be arbitrarily large. (Reason: error scales with the input, but the frequency of the sin function does not.) (In case you can't tell, I only have studied this stuff as a student. :P) -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: better way for ' '.join(args) + '\n'?
On Fri, Oct 26, 2012 at 09:49:50AM +0200, Ulrich Eckhardt wrote: Hi! General advise when assembling strings is to not concatenate them repeatedly but instead use string's join() function, because it avoids repeated reallocations and is at least as expressive as any alternative. What I have now is a case where I'm assembling lines of text for driving a program with a commandline interface. In this scenario, I'm currently doing this: args = ['foo', 'bar', 'baz'] line = ' '.join(args) + '\n' Assuming it's the length of the list that's the problem, not the length of the strings in the list... args = ['foo', 'bar', 'baz'] args[-1] = args[-1] + '\n' line = ' '.join(args) \t -- http://mail.python.org/mailman/listinfo/python-list
Re: better way for ' '.join(args) + '\n'?
On 10/26/2012 05:26 PM, Tycho Andersen wrote: On Fri, Oct 26, 2012 at 09:49:50AM +0200, Ulrich Eckhardt wrote: Hi! General advise when assembling strings is to not concatenate them repeatedly but instead use string's join() function, because it avoids repeated reallocations and is at least as expressive as any alternative. What I have now is a case where I'm assembling lines of text for driving a program with a commandline interface. In this scenario, I'm currently doing this: args = ['foo', 'bar', 'baz'] line = ' '.join(args) + '\n' Assuming it's the length of the list that's the problem, not the length of the strings in the list... args = ['foo', 'bar', 'baz'] args[-1] = args[-1] + '\n' line = ' '.join(args) \t Main problem with that is the trailing space before the newline. If that's not a problem, then fine. Not sure why we try so hard to optimize something that's going to take negligible time. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: better way for ' '.join(args) + '\n'?
On Fri, Oct 26, 2012 at 05:36:50PM -0400, Dave Angel wrote: On 10/26/2012 05:26 PM, Tycho Andersen wrote: Assuming it's the length of the list that's the problem, not the length of the strings in the list... args = ['foo', 'bar', 'baz'] args[-1] = args[-1] + '\n' line = ' '.join(args) \t Main problem with that is the trailing space before the newline. If that's not a problem, then fine. What trailing space before the newline? The other solutions have it, the above does not. However, the above does mutate args, which isn't all that great. Alas, if you want the performance of mutable structures, you're probably going to have to mutate something. (In any case, it's easy enough to change it back, though ugly.) Not sure why we try so hard to optimize something that's going to take negligible time. The same reason some people enjoy sporting events: it's fun :-) \t -- http://mail.python.org/mailman/listinfo/python-list
Re: How to set 250000 baud rate in pyserial ?
Error is like cannot set special baud rate. But as I said pyserial set this speed without problem for ttyUSB0 So it seems pyserial uses diefferent code depending of port type. I tried to simlink ln -s ttyACM0 ttyUSB0 but it does not work On Thursday, October 25, 2012 9:11:23 PM UTC+3, Dennis Lee Bieber wrote: On Thu, 25 Oct 2012 04:09:56 -0700 (PDT), kura...@gmail.com declaimed the following in gmane.comp.python.general: I use Arduino 1280 and Arduino 2560 under Fedora 15. 1280 creates ttyUSB0 port and can be set at 250 successfully. 2560 creates ttyACM0 port and can be only set at speeds from list (no 25) in pyserial. How to set 25 to ttyACM0 port?? Need I patch kernel or python? You don't say what error you are receiving but looking at the source (serialposix.py) implies that it accepts nearly anything on Linux, and relies on the OS returning a success/failure if the value is allowed or not. xxxBSD, SunOS, HPUX, IRIX, and CYGWIN systems don't allow special baudrates at all. .NET, JVM, and Windows don't seem to have explicit call outs for bad rates -- just a generic port configured OK test. -- Wulfraed Dennis Lee Bieber AF6VN wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On 26Oct2012 09:10, Paul Rubin no.email@nospam.invalid wrote: | However, if the as can be part of an expression as in Chris Angelico's | post, Chris's suggestion | | while (client.spop(profile_ids) as profile_id) is not None: | print profile_id | | looks good to me. Now this pulls me from a -0 to a +0.5. Instead of burdening the control constructs with further structure, make as a binding operation for keeping intermediate results from expressions. It will work anywhere an expression is allowed, and superficially doesn't break stuff that exists if as has the lowest precedence. Any doco would need to make it clear that no order of operation is implied, so that this: x = 1 y = (2 as x) + x does not have a defined answer; might be 2, might be 3. Just like any other function call with side effects. Speaking for myself (of course!), I definitely prefer this to adding as as a post expression struction on if/while/etc. I'm not +1 because to my mind it still presents a way for assignment/binding to not be glaringly obvious at the left hand side of an expression. It would probably mean folding the except/with as uses back into expressions and out of the control-structural part of the grammar. I can't see that that would actually break any existing code though - anyone else? Cheers, -- Cameron Simpson c...@zip.com.au UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. - Doug Gwyn -- http://mail.python.org/mailman/listinfo/python-list
Re: How to set 250000 baud rate in pyserial ?
On 10/26/2012 04:01 PM, kura...@gmail.com wrote: Error is like cannot set special baud rate. But as I said pyserial set this speed without problem for ttyUSB0 So it seems pyserial uses diefferent code depending of port type. I tried to simlink ln -s ttyACM0 ttyUSB0 but it does not work No the difference in how baud rate is set is most likely in the driver. pyserial just uses standard kernel apis and ioctls to control the device. -- http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On Fri, Oct 26, 2012 at 4:03 PM, Cameron Simpson c...@zip.com.au wrote: It will work anywhere an expression is allowed, and superficially doesn't break stuff that exists if as has the lowest precedence. Please, no. There is no need for it outside of while expressions, and anywhere else it's just going to be bad practice. Even if it's considered an expression, let's only allow it in while expressions. Any doco would need to make it clear that no order of operation is implied, so that this: x = 1 y = (2 as x) + x does not have a defined answer; might be 2, might be 3. Just like any other function call with side effects. Actually, the docs are clear that expressions are evaluated left to right, so the expected result of the above would be 4. It would probably mean folding the except/with as uses back into expressions and out of the control-structural part of the grammar. I can't see that that would actually break any existing code though - anyone else? Yes it would, because the meaning is a bit different in both of those cases. For except, the result of the expression (an exception class or tuple of classes) is not stored in the target; the exception *instance* is. Similarly for with, the result of the expression is not stored; the result of calling its __enter__ method is, which is often but not always the same thing. -- http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On Fri, Oct 26, 2012 at 1:12 AM, Dan Loewenherz dloewenh...@gmail.com wrote: It seems the topic of this thread has changed drastically from the original message. 1) while EXPR as VAR in no way says that EXPR must be a boolean value. In fact, a use case I've run into commonly in web development is popping from a redis set. E.g. client = StrictRedis() while True: profile_id = client.spop(profile_ids) if not profile_id: break print profile_id In this case, profile_id is None when the loop breaks. It would be much more straightforward (and more Pythonic, IMO), to write: client = StrictRedis() while client.spop(profile_ids) as profile_id: print profile_id For loops are pythonic. You can do this in Python today: client = StrictRedis() for profile_id in iter(lambda: client.spop(profile_ids), None): pass I would like a better iter(), rather than a better while loop. It is irritating to pass in functions that take arguments, and it is impossible to, say, pass in functions that should stop being iterated over when they return _either_ a None or a, say, False. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On Fri, Oct 26, 2012 at 2:23 AM, Chris Angelico ros...@gmail.com wrote: while (client.spop(profile_ids) as profile_id) is not None: print profile_id Why is everyone skirting around C-style assignment expressions as though they're simultaneously anathema and the goal? :) Why should these two statements behave differently? :( with foo() as bar: bar.baz() with (foo() as bar): bar.baz() I don't understand why everyone is so attached to this as syntax. It's confusing because it behaves subtly differently than how it works in with, and it puts the variable on the wrong side of the assignment operator. (I've always been partial to :=, personally.) -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On 10/26/12 17:03, Cameron Simpson wrote: On 26Oct2012 09:10, Paul Rubin no.email@nospam.invalid wrote: | while (client.spop(profile_ids) as profile_id) is not None: Now this pulls me from a -0 to a +0.5. Any doco would need to make it clear that no order of operation is implied, so that this: x = 1 y = (2 as x) + x does not have a defined answer; might be 2, might be 3. Just like any other function call with side effects. I really don't like undefined (or underdefined) specs. If it was to be PEP'd out, I'd want to address as many edge cases as possible. Such as y = (2 as x) + (3 as x) + (4 as x) y = (2 as x) + 4 as x y = booleanish and (2 as x) or (4 as x) y = booleanish and 2 or 4 as x y = (2 as x) if booleanish else (3 as x) y = (2 as x) if booleanish else (3 as z) regardless of how $PEJORATIVE, that's a dumb thing to do! it is. I hate C for how underdefined a lot of corners are. (amongst my hatreds of C are such diverse elements as: underdefined corners, a pitiful standard library, the ease of shooting yourself in the foot, ...) I'm not +1 because to my mind it still presents a way for assignment/binding to not be glaringly obvious at the left hand side of an expression. I think this is why I like it in the while (and could be twisted into accepting it for if) because it also introduces an implied/actual scope for which the variable is intended. In an arbitrary evaluation/assignment, it's much easier to lose the definition nature of it at the top of a block. -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: SSH Connection with Python
On 10/25/2012 12:47 PM, Kamlesh Mutha wrote: You can use paramiko module. Very easy to use. I also use paramiko for a small script. However I'm a little hesitant to use paramik for new code. The web page says: last updated 21-May-2011 and the github url http://github.com/robey/paramiko/ yields me a 404 However I didn't really find any alternative. For cross platform scripts (Linux / windows) subprocess is not such a good alternative. Another problem is, that paramiko depends on pycrypto 2.1+ which doesn't exist as binary release for python 2.7 Is fabric capable of performing scp / sftp Is there any other library as alternative? -- http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On Fri, Oct 26, 2012 at 4:12 PM, Devin Jeanpierre jeanpierr...@gmail.comwrote: For loops are pythonic. You can do this in Python today: client = StrictRedis() for profile_id in iter(lambda: client.spop(profile_ids), None): pass I would like a better iter(), rather than a better while loop. It is irritating to pass in functions that take arguments, and it is impossible to, say, pass in functions that should stop being iterated over when they return _either_ a None or a, say, False. You can kind of do this by creating a class implementing __eq__ and passing that in as the sentinal to the iter method. class FlexibleEquality(object): def __init__(self, *candidates): self.candidates = candidates def __eq__(self, other): return any(other == candidate for candidate in self.candidates) client = StrictRedis() for profile_id in iter(lambda: client.spop(profile_ids), FlexibleEquality(False, None)): pass But this is yucky. I'd much rather have something a bit more clear to the reader. The above is somewhat convoluted. I would far prefer for while EXPR as VAR to run through the results of EXPR as an iterable and continue the loop if any of the values in the iterable is truthy, maybe passing only the first value of the iterable to VAR. Gives maximum flexibility with the cleanest resulting code. client.spop(profile_ids) # conditional succeeds, '123' passed to profile_id '123', True client.spop(profile_ids) # conditional succeeds, '' passed to profile_id '', True client.spop(profile_ids) # conditional fails '', False Dan -- http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On Fri, Oct 26, 2012 at 6:03 PM, Cameron Simpson c...@zip.com.au wrote:
Any doco would need to make it clear that no order of operation is
implied, so that this:
x = 1
y = (2 as x) + x
does not have a defined answer; might be 2, might be 3. Just like any
other function call with side effects.
But function calls with side effects _do_ have a defined order of
evaluation. Left to right. And the answer should be 4.
http://docs.python.org/reference/expressions.html#evaluation-order
def set_(d, k, v):
... d[k] = v
... return v
...
d = {}
set_(d, 'x', 1)
1
set_(d, 'y', set_(d, 'x', 2) + d['x'])
4
-- Devin
--
http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On 26Oct2012 19:41, Devin Jeanpierre jeanpierr...@gmail.com wrote:
| On Fri, Oct 26, 2012 at 6:03 PM, Cameron Simpson c...@zip.com.au wrote:
| Any doco would need to make it clear that no order of operation is
| implied, so that this:
|
|x = 1
|y = (2 as x) + x
|
| does not have a defined answer; might be 2, might be 3. Just like any
| other function call with side effects.
|
| But function calls with side effects _do_ have a defined order of
| evaluation. Left to right.
| And the answer should be 4.
| http://docs.python.org/reference/expressions.html#evaluation-order
No. Separate _expressions_ are evaluated left to right.
So this:
f(1), f(2)
calls f(1) first, then f(2). But this:
f(1) + f(2)
need not do so. Counter-documentation welcomed, but the doco you cite
does not define an order for the second example above.
|
| def set_(d, k, v):
| ... d[k] = v
| ... return v
| ...
| d = {}
| set_(d, 'x', 1)
| 1
| set_(d, 'y', set_(d, 'x', 2) + d['x'])
| 4
That may just be a coincidence of implementation - there's no special
reason to change the evaluation order form the lexical order there, but
expression optimisers should have a free hand generally.
Cheers,
--
Cameron Simpson c...@zip.com.au
Acceptance Testing: Dropping your mods straight into the production
environment to see if the users will accept them.
--
http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On Fri, Oct 26, 2012 at 7:41 PM, Dan Loewenherz dloewenh...@gmail.com wrote: -- snip insanity -- But this is yucky. I'd much rather have something a bit more clear to the reader. That's why I said I wanted a better iter, not some equality-overriding object strawman thing. I was thinking more like this: for profile_id in iter(None)(client.spop, profile_ids): or alternatively: for profile_id in iter(bool)(client.spop, profile_ids): Or perhaps either as keyword arguments (which is the only reason I curried iter). The interesting case for in-place assignment is not here. This is a trivial case. It's in cases like this: while True: x = foo(bar()) if x is None: break if x % 2 == 0: break print x Imagine doing that with iter. :) -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On Fri, Oct 26, 2012 at 7:56 PM, Cameron Simpson c...@zip.com.au wrote: No. Separate _expressions_ are evaluated left to right. So this: f(1), f(2) calls f(1) first, then f(2). But this: f(1) + f(2) need not do so. Counter-documentation welcomed, but the doco you cite does not define an order for the second example above. Actually, it does. Both f(1) and f(2) are separate (sub-)expressions in f(1) + f(2). More to the point, it gives the following example: In the following lines, expressions will be evaluated in the arithmetic order of their suffixes: ... expr1 + expr2 * (expr3 - expr4) I sympathize with your concern, though. Order of evaluation is very bitey, and it's better to be safe than sorry. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On 26Oct2012 18:26, Tim Chase s...@thechases.com wrote: | On 10/26/12 17:03, Cameron Simpson wrote: | On 26Oct2012 09:10, Paul Rubin no.email@nospam.invalid wrote: | | while (client.spop(profile_ids) as profile_id) is not None: | | Now this pulls me from a -0 to a +0.5. | | Any doco would need to make it clear that no order of operation is | implied, so that this: | |x = 1 |y = (2 as x) + x | | does not have a defined answer; might be 2, might be 3. Just like any | other function call with side effects. | | I really don't like undefined (or underdefined) specs. If it was to | be PEP'd out, I'd want to address as many edge cases as possible. I would not. Big time. One of the reasons C is so successful as a lower level language is that by defining only what is needed to be defined to make it _possible_ to get predictable and useful behaviour, maximum flexibility is left for implementation to adapt to particular environments as freely as possible. Pinning down all the corner cases is in general a bad idea, IMO. Every corner case you pin down is an early decision for inflexibility that may later prove to be illfounded. Specify what _needs_ to be specified to achieve the required effect. And stay the hell away from things that only constraint outcomes while not providing the required effect. To take an obvious counter example: your stance would encourage defining the iteration order of dictionary keys. To no good purpose, merely to present definition of _all_ operations instead of just the necessary operations. | Such as | y = (2 as x) + (3 as x) + (4 as x) | y = (2 as x) + 4 as x I would want these to be ambiguous, myself. | y = booleanish and (2 as x) or (4 as x) | y = booleanish and 2 or 4 as x | y = (2 as x) if booleanish else (3 as x) | y = (2 as x) if booleanish else (3 as z) None of these is ambiguous. The second one could be harder to read and want some brackets purely for clarity, but it is perfectly well defined in outcome already. | regardless of how $PEJORATIVE, that's a dumb thing to do! it is. No, sometimes dumb things should remain bad ideas. Defining them to all just makes them no longer obviously bad ideas, merely subtly bad ideas. And subtly bad ideas are worse! | I hate C for how underdefined a lot of corners are. (amongst my | hatreds of C are such diverse elements as: underdefined corners, a | pitiful standard library, the ease of shooting yourself in the foot, | ...) The C standard library was pretty good for when it came out. And the higher up the available facilities tree you go the more choices there are about how something should be done. C is still one of my favourite languages in its domain, though I haven't used it much for several years. If you're uncomfortable with C, try to stay away from it. (I try to stay away from C++ and its bretheren for similar reasons.) | I'm not +1 because to my mind it still presents a way for | assignment/binding to not be glaringly obvious at the left hand side of | an expression. | | I think this is why I like it in the while (and could be twisted | into accepting it for if) because it also introduces an | implied/actual scope for which the variable is intended. A conceptual scope, sure. Presumably not a real one in Python... | In an | arbitrary evaluation/assignment, it's much easier to lose the | definition nature of it at the top of a block. I'm not sure I agree here. Code example? Cheers, -- Cameron Simpson c...@zip.com.au Everything should be made as simple as possible, but no simpler. - Albert Einstein -- http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On 27Oct2012 10:56, I wrote: | On 26Oct2012 19:41, Devin Jeanpierre jeanpierr...@gmail.com wrote: | | But function calls with side effects _do_ have a defined order of | | evaluation. Left to right. | | And the answer should be 4. | | http://docs.python.org/reference/expressions.html#evaluation-order | | No. Separate _expressions_ are evaluated left to right. [...] | need not do so. Counter-documentation welcomed, but the doco you cite | does not define an order for the second example above. [...] On 26Oct2012 16:48, Ian Kelly ian.g.ke...@gmail.com wrote: | does not have a defined answer; might be 2, might be 3. Just like any | other function call with side effects. | Actually, the docs are clear that expressions are evaluated left to | right, so the expected result of the above would be 4. Ian, Devin, my apologies. You're right, the docs are clear and my brain is foggy. So, no ambiguity about that with the suggested as operator. -- Cameron Simpson c...@zip.com.au Well, if you didn't struggle so much, you wouldn't get rope burns. -- http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On 26Oct2012 16:48, Ian Kelly ian.g.ke...@gmail.com wrote: | On Fri, Oct 26, 2012 at 4:03 PM, Cameron Simpson c...@zip.com.au wrote: | It will work anywhere an expression is allowed, and superficially | doesn't break stuff that exists if as has the lowest precedence. | | Please, no. There is no need for it outside of while expressions, and | anywhere else it's just going to be bad practice. Even if it's | considered an expression, let's only allow it in while expressions. We might just have to differ here. | It would probably mean folding the except/with as uses back into | expressions and out of the control-structural part of the grammar. I can't | see that that would actually break any existing code though - anyone else? | | Yes it would, because the meaning is a bit different in both of those | cases. For except, the result of the expression (an exception class | or tuple of classes) is not stored in the target; the exception | *instance* is. Similarly for with, the result of the expression is | not stored; the result of calling its __enter__ method is, which is | often but not always the same thing. Hmm. Good points. Possibly damning points. except (E1, E2) as c as d: anyone? I should hope not! I may be back to +0 now:-( +0.5 for being able to get at partial expression results somehow, -0.1 for the conflict above. Cheers, -- Cameron Simpson c...@zip.com.au Every \item command in item_list must have an optional argument. - Leslie Lamport, LaTeX -- http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On Fri, 26 Oct 2012 19:12:17 -0400, Devin Jeanpierre wrote: I would like a better iter(), rather than a better while loop. It is irritating to pass in functions that take arguments, and it is impossible to, say, pass in functions that should stop being iterated over when they return _either_ a None or a, say, False. Write a trivial helper function. Not everything has to be a one-liner or a built-in. def iterate_until_none_or_false(func, *args, **kwargs): while True: x = func(*args, **kwargs) # Halt if x is None or False, but not other falsey values. if x is None or x is False: return yield x for x in iterate_until_none_or_false( some_function, 1, 2, c, spam=yummy): process(x) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On 26Oct2012 19:19, Devin Jeanpierre jeanpierr...@gmail.com wrote: | (I've always been partial to :=, personally.) I'm less so. It is hard to type (on my keyboard anyway, that's a shifted keystroke followed by an unshifted one). I mank that up often enough that I would resent it for something as oft used as an assignment. Visually, yes, it's good. I was happy with it in Pascal and its like, though I find the succinctness of plain = very attractive given that it is only available on the left in Python, where it is easy to see and not prone to mixups with == later in an expression. Cheers, -- Cameron Simpson c...@zip.com.au George, discussing a patent and prior art: Look, this publication has a date, the patent has a priority date, can't you just compare them? Paul Sutcliffe: Not unless you're a lawyer. -- http://mail.python.org/mailman/listinfo/python-list
Re: SSH Connection with Python
In article mailman.2915.1351294793.27098.python-l...@python.org, Gelonida N gelon...@gmail.com wrote: Another problem is, that paramiko depends on pycrypto 2.1+ which doesn't exist as binary release for python 2.7 I'm running paramiko-1.7.6 with python 2.7.3 on my Ubunto Precise box. I'm reasonably sure all I did was pip install paramiko. On the other hand, it may have built it from source during the install. Generally, I just let pip do it's magic and don't worry about the details. If you're in an environment where you don't have the compiler tool chain, you may be more constrained. Is fabric capable of performing scp / sftp Fabric uses ssh to make connections, and it is capable of copying files. For all intents and purposes, I'd say that means it is capable of performing scp / sftp (both of which are just front-ends to the same basic ssh protocol. But, keep in mind that fabric depends on paramiko. If you can't get paramiko installed, you probably can't get fabric either. -- http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On Fri, Oct 26, 2012 at 8:18 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: I would like a better iter(), rather than a better while loop. It is irritating to pass in functions that take arguments, and it is impossible to, say, pass in functions that should stop being iterated over when they return _either_ a None or a, say, False. Write a trivial helper function. Not everything has to be a one-liner or a built-in. You are missing the point. I was suggesting that the use case of new syntax might be satisfied instead by new functions, which are clearly preferable to new syntax from the perspective your rebuttal comes from. Indeed, one could write those helper functions, and use them, without any changes to Python being made at all! -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On Sat, Oct 27, 2012 at 10:19 AM, Devin Jeanpierre jeanpierr...@gmail.com wrote: On Fri, Oct 26, 2012 at 2:23 AM, Chris Angelico ros...@gmail.com wrote: while (client.spop(profile_ids) as profile_id) is not None: print profile_id Why is everyone skirting around C-style assignment expressions as though they're simultaneously anathema and the goal? :) Why should these two statements behave differently? :( with foo() as bar: bar.baz() with (foo() as bar): bar.baz() I don't understand why everyone is so attached to this as syntax. It's confusing because it behaves subtly differently than how it works in with, and it puts the variable on the wrong side of the assignment operator. (I've always been partial to :=, personally.) I'm not attached to as, myself. It puts the variable at the wrong end, and feels backward compared to a convention that exists elsewhere in the language (regular variable assignment). This is a much stronger backwardness issue than the Python ternary operator (which is only backward in comparison to other languages). Personally, I'm quite happy with assignment itself being an expression. But since that's unlikely to be directly accepted in Python, I would be looking for something as general as possible - something that can truly be used _anywhere_ - rather than a specific while-statement enhancement. Capturing partial expression results is an extremely convenient thing to do. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
how to change os.popen4 to subprocess
Hi, I'm new to python and I'm trying to porting some scripts from v0.96 to v2.0.1. A piece of code is like this: cmd_h = os.popen4(env['SYSCMDLINE'])[1] the system indicates the popen4 is deprecated and suggest to use subprocess. Can anybody tell me how to use subprocess in this case? and what does [1] here means? thanks. -- http://mail.python.org/mailman/listinfo/python-list
attaching names to subexpressions
I have been reading the thread while expression feature proposal, and one of the interesting outcomes of the thread is the idea that Python could allow you to attach names to subexpressions, much like C allows. In C you can say something like this: tax_next_year = (new_salary = salary * (1 + raise)) * tax_rate To avoid the = pitfall, folks have proposed something like this for Python: tax_next_year = ((salary * (1 + raise)) as new_salary) * tax_rate print new_salary, tax_next_year The basic rule in Python is that you can only do one assignment per line of code, which generally forces you to write more readable code IMHO: new_salary = salary * (1 + raise) tax_next_year = new_salary * tax_rate print new_salary, tax_next_year The above code is slightly more verbose than the as proposal would permit, but the latter code is arguably easier for a human to parse, and it's also very amenable to print debugging and/or defensive coding: new_salary = salary * (1 + raise) print new_salary assert new_salary salary tax_next_year = new_salary * tax_rate print new_salary, tax_next_year If the problem statement is How do I name subexpression?, then Python already has a clear path--break your code up into multiple lines. I'm wondering where this simple solution really breaks down from a readability perspective. Perhaps with short-circuited boolean expressions? -- http://mail.python.org/mailman/listinfo/python-list
Re: how to change os.popen4 to subprocess
On 2012-10-27 03:28, skyworld wrote: Hi, I'm new to python and I'm trying to porting some scripts from v0.96 to v2.0.1. A piece of code is like this: cmd_h = os.popen4(env['SYSCMDLINE'])[1] the system indicates the popen4 is deprecated and suggest to use subprocess. Can anybody tell me how to use subprocess in this case? and what does [1] here means? os.popen4 returns a tuple of (child_stdin, child_stdout_and_stderr). The [1] gets the child_stdout_and_stderr member. Using the subprocess module: # Untested! cmd_h = subprocess.Popen(env['SYSCMDLINE'], stdout=subprocess.PIPE, stderr=subprocess.STDOUT, shell=True).stdout Explanation: The command line: env['SYSCMDLINE'] Return stdout: stdout=subprocess.PIPE stderr should be combined with stdout: stderr=subprocess.STDOUT Let the shell parse the command line: shell=True -- http://mail.python.org/mailman/listinfo/python-list
Re: how to change os.popen4 to subprocess
On 27/10/2012 03:28, skyworld wrote: Hi, I'm new to python and I'm trying to porting some scripts from v0.96 to v2.0.1. A piece of code is like this: What software are you talking about here, it's certainly not Python versions as the most up to date are 2.7.3 and 3.3.0? cmd_h = os.popen4(env['SYSCMDLINE'])[1] the system indicates the popen4 is deprecated and suggest to use subprocess. Can anybody tell me how to use subprocess in this case? and what does [1] here means? If you don't know what the [1] means you've got problems :) I suggest you read the tutorial here first http://docs.python.org/tutorial/index.html then the subprocess module here http://docs.python.org/library/subprocess.html#module-subprocess, specifically http://docs.python.org/library/subprocess.html#subprocess-replacements thanks. No problem. -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes: There's no need for it *inside* of while expressions. It doesn't add to the expressiveness of the language, or increase the power of the language, or help people write correct code. It saves one trivial line of code in some, but not all, while loops, at the cost of increasing the complexity of the language and parser. I'm maybe +0.25 on the suggestion but it does save more than one line in the places where it's useful, plus improves clarity. You get to write while (foo() as x) is not None: ... instead of while True: x = foo() if x is not None: break ... which is much uglier. Maybe there are even times when you want while (left() as x) != (right() as y): ... that is even messier when expanded out. There was also the cascaded regexp match example, that happens regularly in real code and that I've hacked various workarounds for, or wished for a Maybe monad. -- http://mail.python.org/mailman/listinfo/python-list
[issue16327] subprocess.Popen leaks file descriptors on os.fork() failure
Charles-François Natali added the comment: No automated testing included because I'm not entirely sure how to replicate this without eating up a ton of ram or doing something naughty with ulimit. Simply use RLIMIT_NPROC, from a subprocess: $ cat /tmp/test.py import subprocess ps = [ ] for i in range(1024): p = subprocess.Popen(['sleep', '10']) ps.append(p) $ python /tmp/test.py Traceback (most recent call last): File /tmp/test.py, line 7, in ? p = subprocess.Popen(['sleep', '10']) File /usr/lib64/python2.4/subprocess.py, line 550, in __init__ errread, errwrite) File /usr/lib64/python2.4/subprocess.py, line 919, in _execute_child self.pid = os.fork() OSError: [Errno 11] Resource temporarily unavailable $ ulimit -u 1024 Not POSIX, but supported by Linux and BSD, which should be enough. The problem with monkey-ptching is that you don't test the real codepath, and it may break in a future version (especially since here it would be using a preivate API). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16327 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16271] weird dual behavior with changing __qualname__; different values observed through attribute and descriptor
Benjamin Peterson added the comment: Here's a patch for 3.4. __qualname__ ought to have been implemented this way in the first place. I'll have to think about what can be done about 3.3. Maybe just the same fix without the removal of PyHeapType.ht_qualname. We can hope no one has written extensions relying on its value actually being correct. -- keywords: +patch nosy: +benjamin.peterson Added file: http://bugs.python.org/file27721/qualname-in-dict.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16271 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16271] weird dual behavior with changing __qualname__; different values observed through attribute and descriptor
Antoine Pitrou added the comment: I'm not sure why this would be the correct way to do it. First you are removing the unicode check, which looks wrong to me. Second, if ht_name works, perhaps ht_qualname can be made to work as well? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16271 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16285] Update urllib to RFC 3986
Changes by Chris Rebert pyb...@rebertia.com: -- nosy: +cvrebert ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16285 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16322] time.tzname on Python 3.3.0 for Windows is decoded by wrong encoding
STINNER Victor added the comment: sys.getfilesystemencoding() 'mbcs' import locale locale.getpreferredencoding() 'cp932' 'cp932' is the same as 'mbcs' in the Japanese environment. And what is the value.of locale.getpreferredencoding(False)? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16322 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16309] PYTHONPATH= different from no PYTHONPATH at all
Changes by Chris Rebert pyb...@rebertia.com: -- nosy: +cvrebert ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16309 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16327] subprocess.Popen leaks file descriptors on os.fork() failure
Charles-François Natali added the comment: Also, I didn't check, but if the problems also occurs on execve() failure, then it's much simpler: simply call Popen() with an invalid/nonexisting executable. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16327 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15494] Move test/support.py into a test.support subpackage
Nick Coghlan added the comment: This whole refactoring project grew out of the fact that Chris and I were looking for somewhere to put common helpers for package testing. Specfically, I wrote a heap of helpers for test_runpy that I wanted to use for the new pkgutil tests. The short term hack (because 3.3 was imminent) is that a couple of the pkgutil tests are *in* test_runpy, not because they belong there, but so they can use those helper utilities. We knew when we did it that wasn't a viable long term solution, but we didn't have a good place to put the helpers so test_pkgutil could get at them - they're packaging specific, so junking up test.support with them would be bad, and we knew from experience that a separate helper module (like script_helper) sucked for discoverability. So, the idea of making test.support a subpackage was born. The current contents of support.py go into the new __init__.py, script_helper moves there to make it more discoverable, and the utilities for packaging tests can move out of test_runpy and into test.support.pkg_helper. Both script_helper and pkg_helper can also be easily covered in the docs under the existing test.support caveat. We didn't start down this road on a whim - we did it because we ran up hard against a clear and obvious problem in the structure of the test suite's support modules. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15494 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16322] time.tzname on Python 3.3.0 for Windows is decoded by wrong encoding
Masami HIRATA added the comment: And what is the value.of locale.getpreferredencoding(False)? import locale locale.getpreferredencoding(False) 'cp932' -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16322 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15498] Eliminate the use of deprecated OS X APIs in getpath.c
Ronald Oussoren added the comment:
Apple seems to have switched to using dlopen in their version of getpath.c (see
http://www.opensource.apple.com/source/python/python-60.3/2.7/fix/getpath.c.ed,
this is the version in OSX 10.8.2)
This causes a problem for some people, as noticed on the pythonmac mailing
list. This is something we should test before applying my patch to avoid
regressions.
Message-Id: 508951d3.7080...@llnl.gov says:
I am trying to work with Apple Mountain Lion's install of Python 2.7. I
have a language interoperability tool, Babel
http://www.llnl.gov/CASC/components/, that used embedded Python when
other languages are calling Python (c.g., C++ calling Python). My
fundamental problem is that sys.path is not being initialized the same
when I dlopen(libpython2.7.dylib) and initialize Python compared with
how the sys.path is set when the Python executable is called directly.
This causes Python to fail to load the numpy module used by Babel.
bash-3.2$ /usr/bin/python2.7 -c import sys; print sys.path; import
numpy /tmp/out1
bash-3.2$ /usr/bin/python -c import sys; print sys.path; import numpy
/tmp/out2
bash-3.2$ cat /tmp/out1
['',
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip',
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7',
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin',
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac',
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages',
'/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python',
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk',
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old',
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload',
'/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC',
'/Library/Python/2.7/site-packages']
bash-3.2$ diff /tmp/out1 /tmp/out2
bash-3.2$ ls -al /usr/bin/python2.7
lrwxr-xr-x 1 root wheel 75 Aug 23 11:10 /usr/bin/python2.7 -
../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7
Presumably, this C program that uses dlopen(), Py_Initialize, and
Py_SimpleString should have exactly the same output.
/** foo.c */
#includedlfcn.h
#includestdio.h
int
main(int argc, char **argv)
{
// void *lptr =
dlopen(/System/Library/Frameworks/Python.framework/Python, RTLD_NOW |
RTLD_GLOBAL);
void *lptr =
dlopen(/System/Library/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib,
RTLD_NOW | RTLD_GLOBAL);
if (lptr) {
void (*pyinit)(void) = dlsym(lptr, Py_Initialize);
if (pyinit) {
int (*runSimple)(const char *);
(*pyinit)(); /* initialize Python */
runSimple = dlsym(lptr, PyRun_SimpleString);
if (runSimple) {
(*runSimple)(import sys ; print sys.path; import numpy);
}
}
else {
fprintf(stderr, Unable to locate Py_Initialize: %s\n, dlerror());
}
}
else {
fprintf(stderr, Error loading Python shared library: %s\n,
dlerror());
}
}
bash-3.2$ gcc foo.c ; ./a.out
['/usr/lib/python27.zip', '/usr/lib/python2.7',
'/usr/lib/python2.7/plat-darwin', '/usr/lib/python2.7/plat-mac',
'/usr/lib/python2.7/plat-mac/lib-scriptpackages',
'/usr/Extras/lib/python', '/usr/lib/python2.7/lib-tk',
'/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload']
Traceback (most recent call last):
File string, line 1, inmodule
ImportError: No module named numpy
However as you see, it has a completely different sys.path. I can't seem
to find a way to get it to initialize Python with the same sys.path. It
seems like the libpython2.7.dylib is broken. I am at a loss on how to
fix this or even who to ask for help.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15498
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16313] Support xz compression in shutil module
Hynek Schlawack added the comment: Isn’t this a dupe of #5411? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16313 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16313] Support xz compression in shutil module
Serhiy Storchaka added the comment: Yes, this is actually a dupe of #5411? Thanks. -- resolution: - duplicate stage: patch review - committed/rejected status: open - closed superseder: - Add xz support to shutil ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16313 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9856] Change object.__format__(s) where s is non-empty to a TypeError
Changes by Berker Peksag berker.pek...@gmail.com: -- nosy: -berker.peksag ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9856 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5411] Add xz support to shutil
Serhiy Storchaka added the comment: I have not seen this issue and was created a new issue16313 with almost same patch as Eric's one (only I have changed the documentation too). Here's the patch. I wonder that it was not committed yet to 3.3. I think it would be better first to add xz support and the code cleanup to do then (if it takes so much time). -- nosy: +serhiy.storchaka versions: +Python 3.4 -Python 3.3 Added file: http://bugs.python.org/file27722/shutil-lzma.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5411 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5411] Add xz support to shutil
Changes by Serhiy Storchaka storch...@gmail.com: -- stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5411 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11468] Improve unittest basic example in the doc
Changes by Berker Peksag berker.pek...@gmail.com: -- nosy: -berker.peksag ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11468 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16327] subprocess.Popen leaks file descriptors on os.fork() failure
Jesús Cea Avión added the comment: The problem with using RLIMIT is that the testsuite could be executing several tests in parallel using independent threads, for instance. You don't want to influence unrelated tests. Overiding private methods is ugly, but if the code evolves the test would break, and the programmer just have to update it. I think that sometimes we have to be practical. There are plenty of examples of this in the testsuite, using implementation details, etc. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16327 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5411] Add xz support to shutil
Changes by Serhiy Storchaka storch...@gmail.com: Removed file: http://bugs.python.org/file27722/shutil-lzma.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5411 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5411] Add xz support to shutil
Serhiy Storchaka added the comment: Oh, I see the '.bz2' bug. Patch updated. -- Added file: http://bugs.python.org/file27723/shutil-lzma_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5411 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16307] multiprocess.pool.map_async callables not working
Hynek Schlawack added the comment: Thanks for taking the time! I remember my frustrations when trying to grok how the mp test suite works. :) A small nit-pick first: you have a lot of extra white space in your patches. Just run 'make patchcheck' first, that should warn you about that. Not sure, but the tests look rather complex to me. I’d humbly propose the the simplified test attached, which also ensures that error_callback get only called on errors and callback on success. Opinions? -- Added file: http://bugs.python.org/file27724/map-async-fix-with-tests.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16307 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15222] mailbox.mbox writes without empty line after each message
lilydjwg added the comment: My system has updated to Python 3.3.0 and this bugs me again :-( I don't see the changes in Python 3.3.0. So when will this be merged into 3.3? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15222 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15222] mailbox.mbox writes without empty line after each message
Petri Lehtinen added the comment: The fix was committed when 3.3.0 was in release candidate mode, and wasn't considered important enough to be included in 3.3.0 anymore. It will be included in 3.3.1, which is to be released next month. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15222 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16327] subprocess.Popen leaks file descriptors on os.fork() failure
Charles-François Natali added the comment: The problem with using RLIMIT is that the testsuite could be executing several tests in parallel using independent threads, for instance. You don't want to influence unrelated tests. That's why I suggested to run it in a subprocess: this is used frequently, e.g. for signal or deadlock tests. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16327 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16307] multiprocess.pool.map_async callables not working
Janne Karila added the comment: Otherwise I agree, but what if one of the callbacks is not called? The test case would fail on assertEqual(2, len(call_args)) but you wouldn't know which callback is the problem. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16307 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4202] Multiple interpreters and readline module hook functions.
Winston451 added the comment: I attached a patch that solve the problem -- keywords: +patch Added file: http://bugs.python.org/file27725/readline.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16324] MIMEText __init__ does not support Charset instance
Changes by Claude Paroz cla...@2xlibre.net: -- keywords: +patch Added file: http://bugs.python.org/file27726/issue16324-1.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16324 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4202] Multiple interpreters and readline module hook functions.
Changes by Winston451 montag...@laposte.net: -- type: - behavior versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4202] Multiple interpreters and readline module hook functions.
Changes by Winston451 montag...@laposte.net: Added file: http://bugs.python.org/file27727/readline.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4202] Multiple interpreters and readline module hook functions.
Changes by Winston451 montag...@laposte.net: Removed file: http://bugs.python.org/file27725/readline.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16328] win_add2path.py sets wrong user path
New submission from Emil Styrke: OS: Windows 7 Ultimate x64 Python version: 2.7.3 x64 win_add2path.py in the scripts directory is supposed to add the Scripts directory according to its source. However, it tries to add $PYTHONPATH/Scripts, when in fact the Scripts directory is at $PYTHONPATH/Tools/Scripts in 2.7. However, it seems like e.g. Setuptools still installs itself in $PYTHONPATH/Scripts, so maybe the right solution is to add both directories. Furthermore, the script sets the default user path to %PATH%, which is not correct at least on windows 7. I have to manually delete this part of the user path to get the user path merged correctly with the system path in cmd.exe. -- components: Demos and Tools, Windows messages: 173840 nosy: Emil.Styrke priority: normal severity: normal status: open title: win_add2path.py sets wrong user path type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16328 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16307] multiprocess.pool.map_async callables not working
Hynek Schlawack added the comment: True, it makes sense to push this assert to the end. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16307 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
