Portable Python 2.7.5.1 released
Dear people, I would like to announce new release of Portable Python based on Python 2.7.5 Included in this release: - PyScripter v2.5.3 NymPy 1.7.1 SciPy 0.12.0 Matplotlib 1.2.1 PyWin32 218 Django 1.5.1 PIL 1.1.7 Py2Exe 0.6.9 wxPython 2.9.4.0 NetworkX 1.7 Lxml 2.3 PySerial 2.5 PyODBC 3.0.6 PyGame 1.9.1 PyGTK 2.24.2 PyQt 4.10.1 IPython 0.13.0 Pandas 0.11.0 Improvements since last release: Upgraded core Python version to fix issues discovered in Python 2.7.4. Snippet from Python 2.7.5 release announcement: 2.7.5 is the latest maintenance release in the Python 2.7 series. You may be surprised to hear from me so soon, as Python 2.7.4 was released slightly more than a month ago. As it turns out, 2.7.4 had several regressions and incompatibilities with 2.7.3. Among them were regressions in the zipfile, gzip, and logging modules. 2.7.5 fixes these. In addition, a data file for testing in the 2.7.4 tarballs and binaries aroused the suspicion of some virus checkers. The 2.7.5 release removes this file to resolve that issue. Installation and use: - After downloading, run the installer, select the packages you would like to install, select the target folder and you are done! In the root folder of the distribution you will find shortcuts for selected applications. Some of the most popular free Python IDE’s come preinstalled and preconfigured with Portable Python. How to use and configure them further please consult their documentation or project sites. Download location: http://portablepython.com/wiki/PortablePython2.7.5.1 Warning: Default installation installs all packages - make sure to review packages selection during installation process as it can take quite some time to install 545MB on the USB drive(s). Please use feedback and support section on the portal to request new packages or to report issues. Keep pythoning ! Perica Zivkovic http://www.PortablePython.com -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
github3.py v0.7.0
Hi all,
github3.py version 0.7.0 was released today. The following is a list
of all changes since 0.6.1:
- Fix ``Issue.close``, ``Issue.reopen``, and ``Issue.assign``. (Issue #106)
- Add ``check_authorization`` to the ``GitHub class`` to cover the `new part
of the API http://developer.github.com/v3/oauth/#check-an-authorization`_.
- Add ``create_file``, ``update_file``, ``delete_file``,
``iter_contributor_statistics``, ``iter_commit_activity``,
``iter_code_frequency`` and ``weekly_commit_count`` to the ``Repository``
object.
- Add ``update`` and ``delete`` methods to the ``Contents`` object.
- Add ``is_following`` to the ``User`` object.
- Add ``head``, ``base`` parameters to ``Repository.iter_pulls``.
- The signature of ``Hook.edit`` has changed since that endpoint has changed
as well. See:
github/developer.github.com@b95f291a47954154a6a8cd7c2296cdda9b610164
- ``github3.GitHub`` can now be used as a context manager, e.g.,
::
with github.GitHub() as gh:
u = gh.user('sigmavirus24')
As of this morning, github3.py is entirely caught up with all recent
changes to the GitHub API. Please note that for the new repository
statistics API that GitHub attempts to cache the results as much as
possible. If they do not have the results cached, though, they will
return a 202 and ask that you give them a moment to generate (and
cache) the results for your request. The documentation for the four
new methods explain how github3.py will communicate a 202 to you. Also
note that those 202 responses *do* affect your rate limit.
Finally, to avoid affecting your rate limit, Repository.update_file,
and Repository.delete_file are implemented separately from
Contents.update and Contents.delete. I agree there should be only one
(obvious) way to do it, but in this case, I feel the versatility of
having two is beneficial to you, the developer.
Cheers,
Ian
--
http://mail.python.org/mailman/listinfo/python-announce-list
Support the Python Software Foundation:
http://www.python.org/psf/donations/
Re: Question about ast.literal_eval
On 20/05/2013 18:12, Steven D'Aprano wrote:
On Mon, 20 May 2013 15:26:02 +0200, Frank Millman wrote:
Can anyone see anything wrong with the following approach. I have not
definitely decided to do it this way, but I have been experimenting and
it seems to work.
[...]
It seems safe to me too, but then any fool can come up with a system
which they themselves cannot break :-)
Thanks for the detailed response.
I think the real worry is validating the column name. That will be
critical.
I would not pass the actual column name to eval(), I would use it to
retrieve a value from a data object and pass that to eval(). However,
then your point becomes 'validating the value retrieved'. I had not
thought about that. I will investigate further.
Personally, I would strongly suggest writing your own mini-
evaluator that walks the list and evaluates it by hand. It isn't as
convenient as just calling eval, but *definitely* safer.
I am not sure I can wrap my mind around mixed 'and's, 'or's, and brackets.
[Thinking aloud]
Maybe I can manually reduce each internal test to a True or False,
substitute them in the list, and then call eval() on the result.
eval('(True and False) or (False or True)')
I will experiment with that.
If you do call eval, make sure you supply the globals and locals
arguments. The usual way is:
eval(expression, {'__builtins__': None}, {})
which gives you an empty locals() and a minimal, (mostly) safe globals.
Thanks - I did not know about that.
Finally, as a belt-and-braces approach, I wouldn't even call eval
directly, but call a thin wrapper that raises an exception if the
expression contains an underscore. Underscores are usually the key to
breaking eval, so refusing to evaluate anything with an underscore raises
the barrier very high.
And even with all those defences, I wouldn't allow untrusted data from
the Internet anywhere near this. Just because I can't break it, doesn't
mean it's safe.
All good advice - much appreciated.
Frank
--
http://mail.python.org/mailman/listinfo/python-list
Re: Question about ast.literal_eval
On 20/05/2013 18:13, Chris Angelico wrote:
On Mon, May 20, 2013 at 11:26 PM, Frank Millman fr...@chagford.com wrote:
0 - for the first entry in the list, the word 'check' (a placeholder - it is
discarded at evaluation time), for any subsequent entries the word 'and' or
'or'.
1 - left bracket - either '(' or ''.
5 - right bracket - either ')' or ''.
I think what you have is safe, but extremely complicated to work with.
Six separate pieces, and things have to be in the right slots... I
think you've spent too many complexity points on the above three
components, and you're getting too little return for them. What
happens if the nesting is mucked up? Could get verrry messy to check.
Combining multiple conditions with a mixture of ands and ors is a
nightmare to try to explain (unless you just point to the Python docs,
which IMO costs you even more complexity points); the only safe option
is to parenthesize everything. The system I pushed for at work (which
was finally approved and implemented a few months ago) is more or less
this: conditions are grouped together into blocks; for each group, you
can choose whether it's all or any (aka and/or), and you choose
whether the overall result is all-groups or any-group. That still
costs a few complexity points (and, btw, our *actual* implementation
is a bit more complicated than that, but I think we could cut it down
to what I just described here without loss of functionality), but it
gives the bulk of what people will actually want without the
complexities of point-and-click code.
The downside of that sort of system is that it requires a two-level
tree. On the flip side, that's often how people will be thinking about
their conditions anyway (eg using a pair of conditions and to
implement a range check - conceptually it's a single check), so that
won't cost too much.
You may be right, Chris, but I don't think my approach is all that bad.
The vast majority of tests will be simple - either a single line, or two
lines for a range check, with no brackets at all.
If the requirement is more complicated than that, well, I don't think
the complication can be avoided, and at least this approach gives full
control.
FWIW, I use the same approach to allow users to construct their own
WHERE clauses in custom views. Again, the vast majority are simple, but
there are times when it can get complicated.
The proof of the pudding will be when I try to get ordinary users to get
their own hands dirty - I am not there yet. If I ever get this released,
the business model will be free software, but support will be charged
for. So if a user gets out of his/her depth, there will be assistance
available.
Time will tell who is right ... ;-)
Frank
--
http://mail.python.org/mailman/listinfo/python-list
Re: Question about ast.literal_eval
On Tue, 21 May 2013 08:30:03 +0200, Frank Millman wrote:
On 20/05/2013 18:12, Steven D'Aprano wrote:
Personally, I would strongly suggest writing your own mini- evaluator
that walks the list and evaluates it by hand. It isn't as convenient as
just calling eval, but *definitely* safer.
I am not sure I can wrap my mind around mixed 'and's, 'or's, and
brackets.
Parsers are a solved problem in computer science, he says as if he had a
clue what he was talking about *wink*
Here's a sketch of a solution... suppose you have a sequence of records,
looking like this:
(bool_op, column_name, comparison_op, literal)
with appropriate validation on each field. The very first record has
bool_op set to or. Then, you do something like this:
import operator
OPERATORS = {
'=': operator.eq,
'is': operator.is_,
'': operator.lt,
# etc.
}
def eval_op(column_name, op, literal):
value = lookup(column_name) # whatever...
return OPERATORS[op](value, literal)
result = False
for (bool_op, column_name, comparison_op, literal) in sequence:
flag = eval_op(column_name, comparison_op, literal)
if bool_op == 'and':
result = result and flag
else:
assert bool_op == 'or'
result = result or flag
# Lazy processing?
if result:
break
and in theory it should all Just Work.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Question about ast.literal_eval
On Tue, May 21, 2013 at 4:46 PM, Frank Millman fr...@chagford.com wrote: You may be right, Chris, but I don't think my approach is all that bad. Frankly, I'm not altogether convinced that our approach is right either :) But like the Oracle in the Matrix, I'm not here to push you to one decision or another so much as to just put the options in front of you and let you make up your own bowdlerized mind. Except in a few cases where I'm really certain of my ground (like don't put any untrusted data through eval()...). The vast majority of tests will be simple - either a single line, or two lines for a range check, with no brackets at all. If the requirement is more complicated than that, well, I don't think the complication can be avoided, and at least this approach gives full control. Yeah, and this is where the issue of complexity points comes in. You're spending a lot of them on functionality that most users won't even use, and those who do will use only occasionally. You're forcing them to match their brackets (not just have the same number of each type, but also to get the nesting correct), and according to your current spec, there can be no more than one open/close bracket at each condition, so they'll have to arbitrarily add dummy conditions to make certain forms of nesting work. You're exposing a lot of the underlying interpreter, while forcing the user to dance wearing a body cast. Sure, it can work, but it's unnecessarily hard. FWIW, I use the same approach to allow users to construct their own WHERE clauses in custom views. Again, the vast majority are simple, but there are times when it can get complicated. Our alpha system is actually online, and we have exactly that system - a query builder that renders down to a WHERE clause. If you're curious, message me offline and I'll give you the URL. The proof of the pudding will be when I try to get ordinary users to get their own hands dirty - I am not there yet. If I ever get this released, the business model will be free software, but support will be charged for. So if a user gets out of his/her depth, there will be assistance available. Time will tell who is right ... ;-) Who is right, and who is dead. Hey, are you aware that both Steven and I come from Australia, and that we are used to having people not trust us? Truly, you have a dizzying intellect! ChrisA ... couldn't resist... -- http://mail.python.org/mailman/listinfo/python-list
Re: How to run a python script twice randomly in a day?
On Tue, May 21, 2013 at 11:12 AM, Cameron Simpson c...@zip.com.au wrote: Ok, good. Some minor remarks: Personally, I always use: #!/bin/sh instead of requiring bash. All UNIX systems have sh, bash is only common. And even when present, it may not be in /bin. /bin/sh is always there, and unless you're doing something quite unusual, it works just fine. Also, on many systems, /bin/sh is a much lighter interpreter than bash (eg Debian uses dash). It's more efficient to use that when you can, even if you use bash for your login shell. On 20May2013 15:05, Avnesh Shakya avnesh.n...@gmail.com wrote: | but when I m using like | | import random | a = random.randrange(0, 59) | */a * * * * bash /home/avin/cronJob/test.sh | then it's showing error becose of varable 'a', so now how can i take | variable? You put that into your crontab? I do not think this means what you think it means; cron does not execute arbitrary Python code. - randrange() is like other python ranges: it does not include the end value. So your call picks a number from 0..58, not 0..59. Say randrange(0,60). Think start, length. Nitpick: It's not start, length; it's start, stop-before. If the start is 10 and the second argument is 20, you'll get numbers from 10 to 19. But your conclusion is still accurate :) ChrisA (two Princess Bride references in as many threads, doing well!) -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about ast.literal_eval
On 21/05/2013 09:21, Steven D'Aprano wrote:
On Tue, 21 May 2013 08:30:03 +0200, Frank Millman wrote:
I am not sure I can wrap my mind around mixed 'and's, 'or's, and
brackets.
Parsers are a solved problem in computer science, he says as if he had a
clue what he was talking about *wink*
Here's a sketch of a solution... suppose you have a sequence of records,
looking like this:
(bool_op, column_name, comparison_op, literal)
with appropriate validation on each field. The very first record has
bool_op set to or. Then, you do something like this:
import operator
OPERATORS = {
'=': operator.eq,
'is': operator.is_,
'': operator.lt,
# etc.
}
def eval_op(column_name, op, literal):
value = lookup(column_name) # whatever...
return OPERATORS[op](value, literal)
result = False
for (bool_op, column_name, comparison_op, literal) in sequence:
flag = eval_op(column_name, comparison_op, literal)
if bool_op == 'and':
result = result and flag
else:
assert bool_op == 'or'
result = result or flag
# Lazy processing?
if result:
break
and in theory it should all Just Work.
That's very clever - thanks, Steven.
It doesn't address the issue of brackets. I imagine that the answer is
something like -
maintain a stack of results
for each left bracket, push a level
for each right bracket, pop the result
or something ...
I am sure that with enough trial and error I can get it working, but I
might cheat for now and use the trick I mentioned earlier of calling
eval() on a sequence of manually derived True/False values. I really
can't see anything going wrong with that.
BTW, thanks to ChrisA for the following tip -
import operator
ops = {
'in':lambda x,y: x in y, # operator.contains has the args backwards
I would have battled with that one.
Frank
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to run a python script twice randomly in a day?
Chris Angelico writes: On 20May2013 15:05, Avnesh Shakya wrote: So your call picks a number from 0..58, not 0..59. Say randrange(0,60). Think start, length. Nitpick: It's not start, length; it's start, stop-before. If the start is 10 and the second argument is 20, you'll get numbers from 10 to 19. But your conclusion is still accurate :) I've sometimes named the latter index past, as in just past the range. I'm also happy to call it just end. The inclusive-style names might be first and last, so past is last + 1. The length of the range from start to end is end - start without a pest term that is either -1 or +1 though I forget which; two consecutive ranges are from b to m, then from m to e; an empty range is from b to b. -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about ast.literal_eval
On 21 May 2013 09:10, Frank Millman fr...@chagford.com wrote: It doesn't address the issue of brackets. I imagine that the answer is something like - maintain a stack of results for each left bracket, push a level for each right bracket, pop the result or something ... Time for me to suggest pyparsing or PLY. You're better off creating your own AST and walking it to produce python or SQL than reinventing the wheel, I think. -- http://mail.python.org/mailman/listinfo/python-list
sympy.nsimplify
For maths nerds like me, this is too cool for words: http://www.johndcook.com/blog/2013/04/30/recognizing-numbers/ -- Steven -- http://mail.python.org/mailman/listinfo/python-list
please help
WAP in python to accept a list of words on STDIN and searches for a line containing all five vowels(a,e,i,o,u) -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about ast.literal_eval
On 21/05/2013 09:23, Fábio Santos wrote: On 21 May 2013 09:10, Frank Millman fr...@chagford.com mailto:fr...@chagford.com wrote: It doesn't address the issue of brackets. I imagine that the answer is something like - maintain a stack of results for each left bracket, push a level for each right bracket, pop the result or something ... Time for me to suggest pyparsing or PLY. You're better off creating your own AST and walking it to produce python or SQL than reinventing the wheel, I think. Or pick one from this lot http://nedbatchelder.com/text/python-parsers.html -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list
Re: please help
On Tue, May 21, 2013 at 6:38 PM, iman.memarp...@gmail.com wrote: WAP in python to accept a list of words on STDIN and searches for a line containing all five vowels(a,e,i,o,u) Homework. Have a shot at it yourself, post your code, show that you can put in some effort. Otherwise we won't see much reason to put in effort for you. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: please help
On 21/05/2013 09:38, iman.memarp...@gmail.com wrote: WAP in python to accept a list of words on STDIN and searches for a line containing all five vowels(a,e,i,o,u) Sorry we don't do your homework for you. But your starter for 10 is to use raw_input on Python 2 or input on Python 3 to fetch data from stdin. I look forward to reviewing your code. -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list
Re: sympy.nsimplify
On Tue, May 21, 2013 at 6:26 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: For maths nerds like me, this is too cool for words: http://www.johndcook.com/blog/2013/04/30/recognizing-numbers/ It is indeed, very cool. I think I need to conjure an excuse to use this someplace. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: How to run a python script twice randomly in a day?
On Tue, May 21, 2013 at 6:21 PM, Jussi Piitulainen jpiit...@ling.helsinki.fi wrote: Chris Angelico writes: On 20May2013 15:05, Avnesh Shakya wrote: So your call picks a number from 0..58, not 0..59. Say randrange(0,60). Think start, length. Nitpick: It's not start, length; it's start, stop-before. If the start is 10 and the second argument is 20, you'll get numbers from 10 to 19. But your conclusion is still accurate :) I've sometimes named the latter index past, as in just past the range. I'm also happy to call it just end. The inclusive-style names might be first and last, so past is last + 1. The length of the range from start to end is end - start without a pest term that is either -1 or +1 though I forget which; two consecutive ranges are from b to m, then from m to e; an empty range is from b to b. Agreed. The inclusive-exclusive range is by far the most useful. There's unfortunately a massive case of lock-in here, but Scripture references would be ever so much more convenient as inc-exc. For instance, today in family devotions we read Galatians 2:1 - 2:21. At a glance, do you know whether that's the entire chapter? What if it were written as Galatians 2 to Galatians 3? Simple! ChrisA -- http://mail.python.org/mailman/listinfo/python-list
64-bit Python for Solaris
Hello python-list,
I'm looking into creating a 32/64-bit Python (2.x and/or 3.x) package
for Solaris. The specificity of that package is that I need to include
both 32-bit and 64-bit binaries in it. The exact way in which the
32/64 support is done is described at [1].
There currently is a Python package that I maintain, which is 32-bit only[2].
I have made an attempt to build a 64-bit package, and my findings are
that the ${prefix}/lib/pythonX.Y/_sysconfigdata.py file contains
system-specific information. Note that it's not ${libdir}/pythonX.Y -
that would have worked, because I'm specifying different ${libdir}
directories when running the 32-bit and 64-bit builds. The Python
installer specifically uses ${prefix}/lib/pythonX.Y. For the most part
is fine, because most of files in there are not architecture-specific,
and it would be quite good to share them among the 32-bit and 64-bit
binaries at runtime. The problem is that some files differ. I've
described it some more at [3].
Ideally, I'd make _sysconfigdata.py return/set different values
depending on the Python runtime that reads it. Something like:
if we're 64-bit:
set values for the 64-bit platform
else:
set values for the 32-bit platform
It's a similar approach to how we currently handle C header files. See
the 'Development packages' section in [1] for more information.
The problem is that it would involve somewhat intrusive patching of
the Python source code, and in long term that means maintainability
issues.
Has this issue been seen before? Is there a better solution? Is there
something that can be done upstream to accommodate this kind of
packaging?
Maciej
[1] http://www.opencsw.org/manual/for-maintainers/32-bit-and-64-bit.html
[2] http://www.opencsw.org/packages/python/
[3] http://lists.opencsw.org/pipermail/maintainers/2013-January/017583.html
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to run a python script twice randomly in a day?
On 21May2013 17:56, Chris Angelico ros...@gmail.com wrote: | On Tue, May 21, 2013 at 11:12 AM, Cameron Simpson c...@zip.com.au wrote: | - randrange() is like other python ranges: it does not include the end value. |So your call picks a number from 0..58, not 0..59. |Say randrange(0,60). Think start, length. | | Nitpick: It's not start, length; it's start, stop-before. If the start | is 10 and the second argument is 20, you'll get numbers from 10 to 19. | But your conclusion is still accurate :) But it's still a useful thing to think when you're trying to reason about ranges unless you're doing something unusual. Cheers, -- Cameron Simpson c...@zip.com.au Life IS pain, highness... anyone who tries to tell you different is trying to sell you something. - Wesley, The_Princess_Bride -- http://mail.python.org/mailman/listinfo/python-list
Re: sympy.nsimplify
Very cool indeed. In the comments was a link to an XKCD cartoon. Its tool tip mentioned twin primes. Looked that up. Google pointed (of course) at Wikipedia. Read that. Backed up to the Google Search, and noticed there is a news item from 15 hours ago that an unknown mathematician at the University of New Hampshire has proven the twin primes conjecture: http://www.wired.com/wiredscience/2013/05/twin-primes/ This is nothing to do with the original post. It's just amazing to me how short the distance between one very interesting topic on the net and something almost unrelated can be. Skip -- http://mail.python.org/mailman/listinfo/python-list
Re: sympy.nsimplify
Skip Montanaro s...@pobox.com writes: Very cool indeed. In the comments was a link to an XKCD cartoon. Its tool tip mentioned twin primes. Looked that up. Google pointed (of course) at Wikipedia. Read that. Backed up to the Google Search, and noticed there is a news item from 15 hours ago that an unknown mathematician at the University of New Hampshire has proven the twin primes conjecture: http://www.wired.com/wiredscience/2013/05/twin-primes/ This is nothing to do with the original post. It's just amazing to me how short the distance between one very interesting topic on the net and something almost unrelated can be. AIUI the twin primes conjecture hasn't been proved. But a significant related fact - that there's an infinitude of primes no more that N apart where N ~ 70,000,000. That might not sound like a lot of progress - but the point is that the existence of some finite bound is very significant. -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 378: Format Specifier for Thousands Separator
This work in 3.1+:
$ python3
Python 3.1.3 (r313:86834, Nov 28 2010, 11:28:10)
[GCC 4.4.5] on linux2
Type help, copyright, credits or license for more information.
one_number = 1234567
print('number={:,}'.format(one_number))
number=1,234,567
paz e amor (love and peace),
Alysson Bruno
===
Palmas(TO)
Brasil
Blog: http://abruno.com
Twitter: http://twitter.com/alyssonbruno
Facebook: http://www.facebook.com/ProfessorAlyssonBruno
=
*Meu alterego Escritor:*
Leia alguns contos que escrevo, não esqueça de me dar sua opinião:
http://goo.gl/Wjn4p http://goo.gl/AXv1g
=
On Tue, May 21, 2013 at 2:44 AM, Ned Deily n...@acm.org wrote:
In article blu176-w10190cb892a0414c988a05d7...@phx.gbl,
Carlos Nepomuceno carlosnepomuc...@outlook.com wrote:
Is there a way to format integers with thousands separator (digit
grouping)
like the format specifier of str.format()?
I'm currently using the following:
sys.stdout.write('Number = %s\n' % '{:,.0f}'.format(x))
Number = 12,345
'x' is unsigned integer so it's like using a sledgehammer to crack a
nut!
I'd like to have something like:
sys.stdout.write('Number = %,u\n' % x)
Is that possible? How can I do it if not already available?
For Python 3.2+ or 2.7, why not just:
print('Number = {:,}'.format(x))
Number = 12,345
--
Ned Deily,
n...@acm.org
--
http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
Static Maps from Lat Long data in XLS file
Hello, I'm new to Python, but I think it can solve my problem and I am looking for a someone to point me to tutorial or give me some tips here. I have an xls file that has about 1,000 latitude and longitude points. I want to do one of two things: 1) Save a static maps and street view image from the coordinates, or 2) create an html file with the map and street view image side by side. I need the urls to look like this: Map with a pin in the centre: http://maps.googleapis.com/maps/api/staticmap?center=43.65162,-79.40571zoom=16size=600x600markers=color:blue%7Clabel:S%7C43.65162,-79.40571sensor=false Image: http://maps.googleapis.com/maps/api/streetview?location=43.65162,%20-79.40571size=600x600sensor=false I am not sure if option 1 will work because the url doesn't actually lead to an image, but rather Google returns an image when that url is used. Any tips or pointers are much appreciated! -- http://mail.python.org/mailman/listinfo/python-list
suggestions for best practices lite for small site deployment with testing
Hi everyone, We've been having a bit of a discussion of this topic over on the Python-UK list (http://mail.python.org/pipermail/python-uk/2013-May/thread.html#2949), and I was a bit shy about mailing out to the big, bad, worldwide Python list, but I'm forcing myself! So I'm writing a book, for O'Reilly, on TDD with Python, and I'm looking for some help and suggestions on my current chapter (well, I'm looking for help and suggestions in general too! i need all the help i can get.). http://www.obeythetestinggoat.com/what-to-say-about-deployment.html So far I've taken the user through building a basic site, and now I want to get them to deploy it. It's very early days, but minimum-viable-product and all that, deploying early + often is a good habit to get into. cf the blog post above for a bit of background. I'm currently leaning away from talking about the various PaaS offerings, they being too many + varied, and I have a bit of a conflict of interest since I work at PythonAnywere. Instead, I'm currently thinking we'll spin up a small linux box, put apache on it, and run both the staging and live site from there. All good stuff to learn... Hopefully some of the lessons will be applicable to PaaSes anyway. So, some questions: provisioning = spinning up a server, installing apache, setting up virtualhost config. confirm I should encourage people to automate this? Am leaning towards just using fabric, is bringing in another tool (chef/puppet/salt) overkill? deployment = updating the source code, database migration, static files. What are your favourite ways of doing this? Shell scripts? Git push hooks? I'm thinking fabric, again... Also: testing -- if the above two steps are automated using fabric, they'll be *functionally* tested because we'll run the functional test suite against the staging site. Any thoughts on whether + how to *unit* test deployment scripts? Take a look at the blog post, and let me know what you think? Bear in mind, at this stage, I'm looking for best practices lite -- at this stage, it's a tiny website, I can always bring in some more complexity later on. The idea is to get people introduced to the idea of deployment, how you automated, and where testing comes in. We don't have to talk about CDNs or zero-downtime or multi-server configuration management yet... Thanks in advance for any thoughts! Harry -- -- Harry J.W. Percival -- Twitter: @hjwp Mobile: +44 (0) 78877 02511 Skype: harry.percival -- http://mail.python.org/mailman/listinfo/python-list
Re: How to run a python script twice randomly in a day?
On 05/21/2013 06:32 AM, Cameron Simpson wrote: On 21May2013 17:56, Chris Angelico ros...@gmail.com wrote: | On Tue, May 21, 2013 at 11:12 AM, Cameron Simpson c...@zip.com.au wrote: | - randrange() is like other python ranges: it does not include the end value. |So your call picks a number from 0..58, not 0..59. |Say randrange(0,60). Think start, length. | | Nitpick: It's not start, length; it's start, stop-before. If the start | is 10 and the second argument is 20, you'll get numbers from 10 to 19. | But your conclusion is still accurate :) But it's still a useful thing to think when you're trying to reason about ranges unless you're doing something unusual. No, it's only happens to look like length when start is zero. So as a mnemonic, it's highly misleading. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Static Maps from Lat Long data in XLS file
On Tue, May 21, 2013 at 9:12 AM, kobe...@gmail.com wrote: Hello, I'm new to Python, but I think it can solve my problem and I am looking for a someone to point me to tutorial or give me some tips here. Hi! I am a first-time poster to python-list, but I think I can help you. I have an xls file that has about 1,000 latitude and longitude points. I want to do one of two things: 1) Save a static maps and street view image from the coordinates, or 2) create an html file with the map and street view image side by side. If you save your xls file as a csv (comma-separated values), you can use python's built-in csv module, documented here - http://docs.python.org/2/library/csv.html, to read the file line by line. Store the values and substitute the strings into a new list of URLs. I need the urls to look like this: Map with a pin in the centre: http://maps.googleapis.com/maps/api/staticmap?center=43.65162,-79.40571zoom=16size=600x600markers=color:blue%7Clabel:S%7C43.65162,-79.40571sensor=false Image: http://maps.googleapis.com/maps/api/streetview?location=43.65162,%20-79.40571size=600x600sensor=false I was able to use curl to grab the images you linked. I believe you can use urllib (or, better, requests - http://docs.python-requests.org/en/latest/) to get and save the images. hth. best, ken -- http://mail.python.org/mailman/listinfo/python-list
Re: Harmonic distortion of a input signal
On 20 May 2013 18:23, jmfauth wxjmfa...@gmail.com wrote: Non sense. The discrete fft algorithm is valid only if the number of data points you transform does correspond to a power of 2 (2**n). As with many of your comments about Python's unicode implementation you are confusing performance with validity. The DFT is defined and is a valid invertible map (barring roundoff) for complex vectors of any integer length. It is also a valid method for understanding the frequency content of periodic signals. The fastest FFT algorithms are for vectors whose length is a power of 2 but the other algorithms produce equally *valid* DFT results. In the example I posted the computation of the DFT using numpy.fft.fft was (as far as I could tell) instantaneous. I could use timeit to discover exactly how many microseconds it took but why when I already have the results I wanted? Keywords to the problem: apodization, zero filling, convolution product, ... eg. http://en.wikipedia.org/wiki/Convolution These points are not relevant to the example given. Oscar -- http://mail.python.org/mailman/listinfo/python-list
How to raise a socket 104 connection reset by peer error
For testing purposes I want my code to raise a socket connection reset by peer error, so that I can test how I handle it, but I am not sure how to raise the error. Any advice appreciated -- http://mail.python.org/mailman/listinfo/python-list
@staticmethods called more than once
Hi,
i'm somewhat confused working with @staticmethods. My logger and configuration
methods are called n times, but I have only one call.
n is number of classes which import the loger and configuration class
in the subfolder mymodule. What might be my mistake mistake?
Many thanks
Christian
### __init__.py ###
from mymodule.MyLogger import MyLogger
from mymodule.MyConfig import MyConfig
# my_test.py ##
from mymodule import MyConfig,MyLogger
#Both methods are static
key,logfile,loglevel = MyConfig().get_config('Logging')
log = MyLogger.set_logger(key,logfile,loglevel)
log.critical(time.time())
#Output
2013-05-21 17:20:37,192 - my_test - 17 - CRITICAL - 1369149637.19
2013-05-21 17:20:37,192 - my_test - 17 - CRITICAL - 1369149637.19
2013-05-21 17:20:37,192 - my_test - 17 - CRITICAL - 1369149637.19
2013-05-21 17:20:37,192 - my_test - 17 - CRITICAL - 1369149637.19
--
http://mail.python.org/mailman/listinfo/python-list
Re: Static Maps from Lat Long data in XLS file
On 05/21/2013 08:12 AM, kobe...@gmail.com wrote: Hello, I'm new to Python, but I think it can solve my problem and I am looking for a someone to point me to tutorial or give me some tips here. I have an xls file that has about 1,000 latitude and longitude points. I want to do one of two things: 1) Save a static maps and street view image from the coordinates, or 2) create an html file with the map and street view image side by side. I need the urls to look like this: Map with a pin in the centre: http://maps.googleapis.com/maps/api/staticmap?center=43.65162,-79.40571zoom=16size=600x600markers=color:blue%7Clabel:S%7C43.65162,-79.40571sensor=false Image: http://maps.googleapis.com/maps/api/streetview?location=43.65162,%20-79.40571size=600x600sensor=false I am not sure if option 1 will work because the url doesn't actually lead to an image, but rather Google returns an image when that url is used. Any tips or pointers are much appreciated! https://pypi.python.org/pypi/xlrd -- --- Tim Daneliuk -- http://mail.python.org/mailman/listinfo/python-list
Re: @staticmethods called more than once
Don't confuse the use of static in Python with its use in C/C++. From a post on StackOverflow: A staticmethod is a method that knows nothing about the class or instance it was called on. It just gets the arguments that were passed, no implicit first argument. It is basically useless in Python -- you can just use a module function instead of a staticmethod. That is, the @staticmethod decorator doesn't mean, call this function once. Skip -- http://mail.python.org/mailman/listinfo/python-list
Re: How to raise a socket 104 connection reset by peer error
On 2013.05.21 10:26, loial wrote: For testing purposes I want my code to raise a socket connection reset by peer error, so that I can test how I handle it, but I am not sure how to raise the error. Arbitrary exceptions can be raised with the raise keyword. In Python 3.3, that exact error got its own builtin exception: http://docs.python.org/3.3/tutorial/errors.html#raising-exceptions http://docs.python.org/3.3/library/exceptions.html#ConnectionResetError In earlier versions of Python, you will have to raise OSError and set its errno attribute. -- CPython 3.3.2 | Windows NT 6.2.9200 / FreeBSD 9.1 -- http://mail.python.org/mailman/listinfo/python-list
Re: @staticmethods called more than once
In 02f0123d-2f9e-4287-b983-cfa1db9db...@googlegroups.com Christian
mining.fa...@gmail.com writes:
Hi,
i'm somewhat confused working with @staticmethods. My logger and
configuration methods are called n times, but I have only one call.
n is number of classes which import the loger and configuration class
in the subfolder mymodule. What might be my mistake mistake?
Many thanks
Christian
### __init__.py ###
from mymodule.MyLogger import MyLogger
from mymodule.MyConfig import MyConfig
# my_test.py ##
from mymodule import MyConfig,MyLogger
#Both methods are static
key,logfile,loglevel = MyConfig().get_config('Logging')
log = MyLogger.set_logger(key,logfile,loglevel)
log.critical(time.time())
#Output
2013-05-21 17:20:37,192 - my_test - 17 - CRITICAL - 1369149637.19
2013-05-21 17:20:37,192 - my_test - 17 - CRITICAL - 1369149637.19
2013-05-21 17:20:37,192 - my_test - 17 - CRITICAL - 1369149637.19
2013-05-21 17:20:37,192 - my_test - 17 - CRITICAL - 1369149637.19
You haven't given us the code for your MyLogger class, so it's difficult
to say exactly what the problem is.
However, I have a guess. Does MyLogger.set_logger() contain a call to
addHandler()? Each call to addHandler() adds another handler to your
logger, and when you call log.critical() [or any other log function] you
get one line of output for each handler.
You should only call addHandler() once.
--
John Gordon A is for Amy, who fell down the stairs
gor...@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, The Gashlycrumb Tinies
--
http://mail.python.org/mailman/listinfo/python-list
Re: @staticmethods called more than once
In kng7n6$efc$1...@reader1.panix.com John Gordon gor...@panix.com writes: You should only call addHandler() once. ...for each intended logging output destination, of course. If you want logging output to appear in a file and on-screen, then you would call addHandler() once with a file handler and once with a screen handler. But I think you may be calling addHandler multiple times for the same file handler, which is causing the duplicate logging output. -- John Gordon A is for Amy, who fell down the stairs gor...@panix.com B is for Basil, assaulted by bears -- Edward Gorey, The Gashlycrumb Tinies -- http://mail.python.org/mailman/listinfo/python-list
Re: @staticmethods called more than once
On 05/21/2013 08:39 AM, Skip Montanaro wrote: Don't confuse the use of static in Python with its use in C/C++. From a post on StackOverflow: A staticmethod is a method that knows nothing about the class or instance it was called on. It just gets the arguments that were passed, no implicit first argument. It is basically useless in Python -- you can just use a module function instead of a staticmethod. For there record, staticmethod is useful when you want to make it possible for subclasses to change behavior. -- ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: @staticmethods called more than once
Am Dienstag, 21. Mai 2013 18:48:07 UTC+2 schrieb John Gordon: In kng7n6$efc$1...@reader1.panix.com John Gordon gor...@panix.com writes: You should only call addHandler() once. ...for each intended logging output destination, of course. If you want logging output to appear in a file and on-screen, then you would call addHandler() once with a file handler and once with a screen handler. But I think you may be calling addHandler multiple times for the same file handler, which is causing the duplicate logging output. -- John Gordon A is for Amy, who fell down the stairs gor...@panix.com B is for Basil, assaulted by bears -- Edward Gorey, The Gashlycrumb Tinies Yes you're right. Many thanks! -- http://mail.python.org/mailman/listinfo/python-list
More general way of generating PyODBC queries as a dict?
Here are my averagely general class methods for creating a dictionary from the
result of database queries:
def make_schema_dict(self):
schema = [i[2] for i in self.cursor.tables()
if i[2].startswith('tbl_') or i[2].startswith('vw_')]
self.schema = {table: {'scheme': [row.column_name for row
in self.cursor.columns(table)]}
for table in schema}
def last_table_query_as_dict(self, table):
return {'data': [{col: row.__getattribute__(col) for col in
self.schema[table]['scheme']
if col != 'RowNum'} for row in self.cursor.fetchall()]}
Unfortunately as you can see, there are many complications.
For example, when multiple tables are queried; some hackish lambdas are
required to generate the resulting dictionary.
Can you think of some more general methods?
(and yes I know this is against the PEP; and that this is also on SO)
--
http://mail.python.org/mailman/listinfo/python-list
RE: PEP 378: Format Specifier for Thousands Separator
From: alyssonbr...@gmail.com
Date: Tue, 21 May 2013 09:03:13 -0300
Subject: Re: PEP 378: Format Specifier for Thousands Separator
To: python-list@python.org
This work in 3.1+:
$ python3
Python 3.1.3 (r313:86834, Nov 28 2010, 11:28:10)
[GCC 4.4.5] on linux2
Type help, copyright, credits or license for more information.
one_number = 1234567
print('number={:,}'.format(one_number))
number=1,234,567
Thank you, but let me rephrase it. I'm already using str.format() but I'd like
to use '%' (BINARY_MODULO) operator instead.
I've looked into the source code of CPython 2.7.5 and I've found no evidence of
the thousands separator been implemented on formatint() in
Objects/unicodeobject.c.
I also didn't find the _PyString_FormatLong() used in formatlong(). Where is
_PyString_FormatLong() located?
So, the question is: Where would I change the CPython 2.7.5 source code to
enable '%' (BINARY_MODULO) to format using the thousands separator like
str.format() does, such as:
sys.stderr.write('%,d\n' % 1234567)
1,234,567
--
http://mail.python.org/mailman/listinfo/python-list
Re: PEP 378: Format Specifier for Thousands Separator
On Tue, May 21, 2013 at 8:49 PM, Carlos Nepomuceno
carlosnepomuc...@outlook.com wrote:
Thank you, but let me rephrase it. I'm already using str.format() but I'd
like to use '%' (BINARY_MODULO) operator instead.
There is no real reason to do this. `str.format()` is the new shiny
thing you should be using all the time. Also, '%' is BINARY_MODULO
(where did you even get that name from?) if and only if you have two
numbers, and it performs the modulo division (eg. 27 % 5 = 2)
So, the question is: Where would I change the CPython 2.7.5 source code to
enable '%' (BINARY_MODULO) to format using the thousands separator like
str.format() does, such as:
sys.stderr.write('%,d\n' % 1234567)
1,234,567
This will make your code unportable and useless, depending on one
patch you made. Please don’t do that. Instead,
sys.stdout.write('Number = %s\n' % '{:,.0f}'.format(x))
Number = 12,345
'x' is unsigned integer so it's like using a sledgehammer to crack a nut!
In Python? Tough luck, every int is signed. And it isn’t just a
sledgehammer, it’s something worse. Just do that:
sys.stdout.write('Number = {:,.0f}\n'.format(x))
Much more peaceful.
You can also do a print, like everyone sane would. Where did you
learn Python from? “Python Worst Practice for Dummies”?
--
Kwpolska http://kwpolska.tk | GPG KEY: 5EAAEA16
stop html mail| always bottom-post
http://asciiribbon.org| http://caliburn.nl/topposting.html
--
http://mail.python.org/mailman/listinfo/python-list
Re: PEP 378: Format Specifier for Thousands Separator
Thank you, but let me rephrase it. I'm already using str.format() but I'd like to use '%' (BINARY_MODULO) operator instead. That's unlikely to change. If not deprecated already string interpolation using the modulo operator has lost favor to the string object's format method. You might be able to get by with a change of your LOCALE setting and/or a peek at the documentation for the locale module. Skip -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 378: Format Specifier for Thousands Separator
On 21/05/2013 20:13, Skip Montanaro wrote: Thank you, but let me rephrase it. I'm already using str.format() but I'd like to use '%' (BINARY_MODULO) operator instead. That's unlikely to change. If not deprecated already string interpolation using the modulo operator has lost favor to the string object's format method. Please stop perpetuating this myth, see http://mail.python.org/pipermail/python-dev/2012-February/116789.html and http://bugs.python.org/issue14123 -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list
RE: PEP 378: Format Specifier for Thousands Separator
From: kwpol...@gmail.com
Date: Tue, 21 May 2013 21:06:11 +0200
Subject: Re: PEP 378: Format Specifier for Thousands Separator
To: carlosnepomuc...@outlook.com
CC: python-list@python.org
On Tue, May 21, 2013 at 8:49 PM, Carlos Nepomuceno
carlosnepomuc...@outlook.com wrote:
Thank you, but let me rephrase it. I'm already using str.format() but I'd
like to use '%' (BINARY_MODULO) operator instead.
There is no real reason to do this. `str.format()` is the new shiny
thing you should be using all the time. Also, '%' is BINARY_MODULO
(where did you even get that name from?) if and only if you have two
numbers, and it performs the modulo division (eg. 27 % 5 = 2)
I did:
def fmt(s):
... return '%s' % s
...
import dis
dis.dis(fmt)
2 0 LOAD_CONST 1 ('%s')
3 LOAD_FAST 0 (s)
6 BINARY_MODULO
7 RETURN_VALUE
Then I've looked for 'BINARY_MODULO' in Python/ceval.c and found:
case BINARY_MODULO:
w = POP();
v = TOP();
if (PyString_CheckExact(v))
x = PyString_Format(v, w);
else
x = PyNumber_Remainder(v, w);
Then I've looked for 'PyString_Format' and found it in Objects/stringobject.c
Analysing the code of stringobject.c I've found formatint() and formatlong().
I'm not using str.format() because it's slower than '%' and because I love '%'.
str.format() looks like Java shit to me!
So, the question is: Where would I change the CPython 2.7.5 source code to
enable '%' (BINARY_MODULO) to format using the thousands separator like
str.format() does, such as:
sys.stderr.write('%,d\n' % 1234567)
1,234,567
This will make your code unportable and useless, depending on one
patch you made. Please don’t do that. Instead,
I'm just learning how to improve things! ;)
sys.stdout.write('Number = %s\n' % '{:,.0f}'.format(x))
Number = 12,345
'x' is unsigned integer so it's like using a sledgehammer to crack a nut!
In Python? Tough luck, every int is signed. And it isn’t just a
sledgehammer, it’s something worse. Just do that:
sys.stdout.write('Number = {:,.0f}\n'.format(x))
Much more peaceful.
Indeed! I just cut and pasted my code to create an example for the message. The
actual format operation isn't done at the sys.stdout.write().
You can also do a print, like everyone sane would. Where did you
learn Python from? “Python Worst Practice for Dummies”?
lol I'm learning from my big mistakes up to now and a ton of online tutorials,
besides Dive into Python (2004)[1], Python Programming (2012)[2] and
Programming Python, 3rd Ed (2006) [print]
print isn't thread safe. That's why I've chosen sys.stdout.write() -- it's
faster and thread safe by default.
I don't need any fancy formating, just need to send the string to screen.
[1] http://www.diveintopython.net/
[1] http://en.wikibooks.org/wiki/Python_Programming
--
Kwpolska http://kwpolska.tk | GPG KEY: 5EAAEA16
stop html mail | always bottom-post
http://asciiribbon.org | http://caliburn.nl/topposting.html
--
http://mail.python.org/mailman/listinfo/python-list
RE: PEP 378: Format Specifier for Thousands Separator
Analysing the code of stringobject.c I've found formatint() and formatlong(). I mean _PyString_FormatLong() -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 378: Format Specifier for Thousands Separator
On 2013.05.21 14:26, Mark Lawrence wrote: On 21/05/2013 20:13, Skip Montanaro wrote: Thank you, but let me rephrase it. I'm already using str.format() but I'd like to use '%' (BINARY_MODULO) operator instead. That's unlikely to change. If not deprecated already string interpolation using the modulo operator has lost favor to the string object's format method. Please stop perpetuating this myth, see http://mail.python.org/pipermail/python-dev/2012-February/116789.html and http://bugs.python.org/issue14123 What myth? People should indeed be using .format(), but no one said % formatting was going away soon. Also, the suggested change to the docs wasn't made and the issue is closed. The current docs do not say that % formatting isn't going to be deprecated, but it does mention its caveats and suggests .format(). If you are trying to say that % formatting will never ever go away, then you are wrong. It is highly unlikely to go away in a 3.x release, but /may/ get phased out in Python 4.0. -- CPython 3.3.2 | Windows NT 6.2.9200 / FreeBSD 9.1 -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 378: Format Specifier for Thousands Separator
On 05/21/2013 12:06 PM, Chris “Kwpolska” Warrick wrote:
On Tue, May 21, 2013 at 8:49 PM, Carlos Nepomuceno wrote:
Thank you, but let me rephrase it. I'm already using str.format() but I'd like
to use '%' (BINARY_MODULO) operator instead.
There is no real reason to do this. `str.format()` is the new shiny
thing you should be using all the time.
.format() is useful, and has it's place, but % formatting is not going away.
So, the question is: Where would I change the CPython 2.7.5 source code to
enable '%' (BINARY_MODULO) to format using the thousands separator like
str.format() does, such as:
-- sys.stderr.write('%,d\n' % 1234567)
1,234,567
This will make your code unportable and useless, depending on one
patch you made. Please don’t do that.
Agreed. Unless you're willing to have your programs either run differently, or not at all, on other systems this is the
wrong way to fix it.
Where did you learn Python from? “Python Worst Practice for Dummies”?
Chris Warrick,
Was that necessary? Useful? Helpful in any way? If you can't be civil, keep
your posts to yourself.
--
~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list
RE: PEP 378: Format Specifier for Thousands Separator
To: python-list@python.org From: breamore...@yahoo.co.uk Subject: Re: PEP 378: Format Specifier for Thousands Separator Date: Tue, 21 May 2013 20:26:41 +0100 On 21/05/2013 20:13, Skip Montanaro wrote: Thank you, but let me rephrase it. I'm already using str.format() but I'd like to use '%' (BINARY_MODULO) operator instead. That's unlikely to change. If not deprecated already string interpolation using the modulo operator has lost favor to the string object's format method. I used to think str.__mod__() was going to be deprecated until Steven told me it was a myth! Think I got that idea from the own Python docs, but it's gone by now. Nevermind... The fact is I have no need for str.format(). It's slow and awkward. str.format() looks like COBOL/Java idiom to me. I love Python! '%' is much more cool!!! Please stop perpetuating this myth, see http://mail.python.org/pipermail/python-dev/2012-February/116789.html and http://bugs.python.org/issue14123 -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: PEP 378: Format Specifier for Thousands Separator
Date: Tue, 21 May 2013 14:53:54 -0500
From: bahamutzero8...@gmail.com
To: python-list@python.org
[...]
What myth? People should indeed be using .format(), but no one said %
formatting was going away soon. Also, the suggested change to the docs
wasn't made and the issue is closed. The current docs do not say that %
formatting isn't going to be deprecated, but it does mention its
caveats and suggests .format(). If you are trying to say that % formatting
will never ever go away, then you are wrong. It is highly
unlikely to go away in a 3.x release, but /may/ get phased out in Python 4.0.
I vote for keeping str.__mod__()!
Anyway, is it possible to overload str.__mod__() without deriving a class? I
mean to have something like:
old_mod = str.__mod__
def new_mod(x):
global old_mod
try:
old_mod(x)
except ValueError, ex:
#catch ValueError: unsupported format character ',' (0x2c) at index 1
#process new '%,d' format here
return '{:,}'.format(x) #just to illustrate the behaviour. it would
have it's own faster code
str.__mod__ = new_mod #this raises TypeError: can't set attributes of
built-in/extension type 'str'
sys.stdout.write('num=%,d\n' % 1234567)
--
CPython 3.3.2 | Windows NT 6.2.9200 / FreeBSD 9.1
--
http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
Modules list-tool
Are anyone aware of a tool that can show me at run-time which modules (pyd/dll) are loaded into a Python program at a specific time (or over time)? To clarify, e.g. when running a sample from PyQt4 (examples\tutorials\addressbook\part1.pyw) and using Process Explorer [1], I can launch WinDbg from it and get this list of modules: ModLoad: 1d00 1d00a000 G:\ProgramFiler\Python27\python.EXE ModLoad: 7c90 7c9b1000 F:\WINDOWS\system32\ntdll.dll ModLoad: 7c80 7c8f7000 F:\WINDOWS\system32\kernel32.dll ModLoad: 1e00 1e261000 f:\windows\system32\python27.dll ModLoad: 7e41 7e4a1000 F:\WINDOWS\system32\USER32.dll ModLoad: 77f1 77f59000 F:\WINDOWS\system32\GDI32.dll ModLoad: 77dc 77e6a000 F:\WINDOWS\system32\ADVAPI32.dll ModLoad: 77e7 77f03000 F:\WINDOWS\system32\RPCRT4.dll ModLoad: 77fe 77ff1000 F:\WINDOWS\system32\Secur32.dll ModLoad: 7c9c 7d1d8000 F:\WINDOWS\system32\SHELL32.dll ModLoad: 77c0 77c58000 F:\WINDOWS\system32\msvcrt.dll ModLoad: 77f6 77fd6000 F:\WINDOWS\system32\SHLWAPI.dll ModLoad: 7852 785c3000 f:\windows\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.6161_x-ww_31a54e43\MSVCR90.dll ModLoad: 7637 7638d000 f:\windows\system32\IMM32.DLL ModLoad: 62f2 62f29000 f:\windows\system32\LPK.DLL ModLoad: 7542 7548b000 f:\windows\system32\USP10.dll ModLoad: 773c 774c3000 f:\windows\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202\comctl32.dll ModLoad: 5d5d 5d66a000 F:\WINDOWS\system32\comctl32.dll ModLoad: 78aa 78b5f000 f:\windows\system32\MSVCR100.dll ModLoad: 00d9 00f29000 g:\ProgramFiler\Python27\lib\site-packages\PyQt4\QtCore.pyd ModLoad: 6700 6726 g:\ProgramFiler\Python27\lib\site-packages\PyQt4\QtCore4.dll ModLoad: 774d 7760e000 F:\WINDOWS\system32\ole32.dll ModLoad: 71aa 71ab7000 f:\windows\system32\WS2_32.dll ModLoad: 71a9 71a98000 f:\windows\system32\WS2HELP.dll ModLoad: 7848 7850e000 f:\windows\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.6161_x-ww_31a54e43\MSVCP90.dll ModLoad: 00a6 00a73000 g:\ProgramFiler\Python27\lib\site-packages\sip.pyd ModLoad: 011f 0177f000 g:\ProgramFiler\Python27\lib\site-packages\PyQt4\QtGui.pyd ModLoad: 6500 657c4000 g:\ProgramFiler\Python27\lib\site-packages\PyQt4\QtGui4.dll ... - My example may be mooth since part1.pyw above (when I enter the debugger) is just waiting for events. The stack of pythonw.exe as shown in Process Explorer: ... ntdll.dll!ZwWaitForMultipleObjects+0xc kernel32.dll!WaitForMultipleObjectsEx+0x12c USER32.dll!RealMsgWaitForMultipleObjectsEx+0x13e QtCore4.dll!QEventDispatcherWin32::processEvents+0x3c3 ntdll.dll!RtlAcquirePebLock+0x28 Is there a tool that can do something similar? (written in Python maybe?). But a bit simpler to use than my current method. Just launch it from the command-line; something like pyXX part1.pyw more args [1] http://technet.microsoft.com/en-gb/sysinternals/bb896653 --gv -- http://mail.python.org/mailman/listinfo/python-list
Re: Translation API in Python
ok MR, I have searched before asking here,but i didn't find thing -- http://mail.python.org/mailman/listinfo/python-list
A computer programmer, web developer and network admin resume
A computer programmer, web developer and network administrator resume. For a resume in HTML or .Doc format click on: www.DatabasePrograms.Bizhttp://www.databaseprograms.biz/ If you would like this in text format instead, please let me know. Daniel Rapaport 1-949-307-2485 i...@databaseprograms.bizmailto:i...@databaseprograms.biz To unsubscribe click on: i...@databaseprograms.biz?Subject=unsubscribemailto:i...@databaseprograms.biz?Subject=unsubscribe -- http://mail.python.org/mailman/listinfo/python-list
Re: @staticmethods called more than once
Ethan Furman於 2013年5月22日星期三UTC+8上午12時30分22秒寫道： On 05/21/2013 08:39 AM, Skip Montanaro wrote: Don't confuse the use of static in Python with its use in C/C++. From a post on StackOverflow: A staticmethod is a method that knows nothing about the class or instance it was called on. It just gets the arguments that were passed, no implicit first argument. It is basically useless in Python -- you can just use a module function instead of a staticmethod. For there record, staticmethod is useful when you want to make it possible for subclasses to change behavior. -- ~Ethan~ I prefer objects in classes with slimer figures not heavily weighted with trivial methods in each instance construction and clone. But this is only my personal style of classes in python. -- http://mail.python.org/mailman/listinfo/python-list
Re: A computer programmer, web developer and network admin resume
On Wed, 22 May 2013 01:15:27 +, i...@databaseprograms.biz wrote: If you would like this in text format instead, please let me know. What if we don't want it at all? -- Denis McMahon, denismfmcma...@gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Myth Busters: % this old style of formatting will eventually be removed from the language
I was looking for something else and just found what I think is the place where I was first exposed to the myth[1]: Since str.format() is quite new, a lot of Python code still uses the % operator. However, because this old style of formatting will eventually be removed from the language, str.format() should generally be used. Is this tutorial outdated or this still an issue? [1] http://docs.python.org/2/tutorial/inputoutput.html#old-string-formatting -- http://mail.python.org/mailman/listinfo/python-list
Re: A computer programmer, web developer and network admin resume
On 2013-05-22 01:15, i...@databaseprograms.biz wrote: A computer programmer, web developer and network administrator ...walk into a bar... So what's the punchline? -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 378: Format Specifier for Thousands Separator
On Tue, 21 May 2013 23:22:24 +0300, Carlos Nepomuceno wrote: Anyway, is it possible to overload str.__mod__() without deriving a class? I mean to have something like: No, not in Python. If you want to monkey-patch built-in classes on the fly, with all the troubles that causes, use Ruby. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
RE: PEP 378: Format Specifier for Thousands Separator
From: steve+comp.lang.pyt...@pearwood.info Subject: Re: PEP 378: Format Specifier for Thousands Separator Date: Wed, 22 May 2013 02:42:56 + To: python-list@python.org On Tue, 21 May 2013 23:22:24 +0300, Carlos Nepomuceno wrote: Anyway, is it possible to overload str.__mod__() without deriving a class? I mean to have something like: No, not in Python. If you want to monkey-patch built-in classes on the fly, with all the troubles that causes, use Ruby. So, the only alternative to have '%,d' % x rendering the thousands separator output would a C source code modification? -- Steven -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 378: Format Specifier for Thousands Separator
On Tue, 21 May 2013 14:53:54 -0500, Andrew Berg wrote: On 2013.05.21 14:26, Mark Lawrence wrote: Please stop perpetuating this myth, see http://mail.python.org/pipermail/python-dev/2012-February/116789.html and http://bugs.python.org/issue14123 What myth? The myth that % string formatting is deprecated. It is not deprecated. People should indeed be using .format(), If it is useful to them, and not too slow, or indeed if they merely want to. And if not, then not. This is a good case where the original poster *should* use str.format, since it does exactly what he wants, and % does not. Python gives you many tools, and the wise man uses the right tool for the job. Sometimes that is % and sometimes it is str.format and sometimes it is string.Template. That str.format looks like Java is irrelevant. Method call syntax is common in Python, and is not original to Java. Besides, Python looks like many languages: some parts look like Java, some parts look like C, some parts remind me of functional languages like Lisp and Haskell, and some parts look like Algol or Pascal. but no one said % formatting was going away soon. True, but only for the definition no one = all the people who insist that % is deprecated, or soon to be deprecated. Also, the suggested change to the docs wasn't made and the issue is closed. The current docs do not say that % formatting isn't going to be deprecated, but it does mention its caveats and suggests .format(). If you are trying to say that % formatting will never ever go away, then you are wrong. It is highly unlikely to go away in a 3.x release, but /may/ get phased out in Python 4.0. What happens in Python 4000 is irrelevant. If somebody is trying to future proof their code for a version that *may never exist*, and if it does exist is likely to be six or eight years away from even starting the design phase, they are wasting their time. It is hard enough to track a moving target, it is impossible to track a target that isn't even a gleam in GvR's eye yet. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: How to run a python script twice randomly in a day?
On 21May2013 09:54, Dave Angel da...@davea.name wrote: | On 05/21/2013 06:32 AM, Cameron Simpson wrote: | On 21May2013 17:56, Chris Angelico ros...@gmail.com wrote: | | On Tue, May 21, 2013 at 11:12 AM, Cameron Simpson c...@zip.com.au wrote: | | - randrange() is like other python ranges: it does not include the end value. | |So your call picks a number from 0..58, not 0..59. | |Say randrange(0,60). Think start, length. | | | | Nitpick: It's not start, length; it's start, stop-before. If the start | | is 10 and the second argument is 20, you'll get numbers from 10 to 19. | | But your conclusion is still accurate :) | | But it's still a useful thing to think when you're trying to reason | about ranges unless you're doing something unusual. | | No, it's only happens to look like length when start is zero. So as | a mnemonic, it's highly misleading. Feh! No self respecting computer scientist would ever count from other than zero! Actually, yes, you're right there. Cheers, -- Cameron Simpson c...@zip.com.au Q: How does a hacker fix a function which doesn't work for all of the elements in its domain? A: He changes the domain. -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 378: Format Specifier for Thousands Separator
On Wed, 22 May 2013 05:56:53 +0300, Carlos Nepomuceno wrote: From: steve+comp.lang.pyt...@pearwood.info Subject: Re: PEP 378: Format Specifier for Thousands Separator Date: Wed, 22 May 2013 02:42:56 + To: python-list@python.org On Tue, 21 May 2013 23:22:24 +0300, Carlos Nepomuceno wrote: Anyway, is it possible to overload str.__mod__() without deriving a class? I mean to have something like: No, not in Python. If you want to monkey-patch built-in classes on the fly, with all the troubles that causes, use Ruby. So, the only alternative to have '%,d' % x rendering the thousands separator output would a C source code modification? That's one alternative. But the language you would be then running will no longer be Python. Another alternative would be to write a pre-processor that parses your Python source code, extracts any reference to the above, and replaces it with a call to the appropriate format call. But not only is that a lot of work for very little gain, but it's also more or less impossible to do in full generality. And again, what you are running will be something different than Python, it will be Python plus a pre-processor. Don't fight the language. You will lose. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Myth Busters: % this old style of formatting will eventually be removed from the language
On 05/21/2013 07:26 PM, Carlos Nepomuceno wrote: I was looking for something else and just found what I think is the place where I was first exposed to the myth[1]: Since str.format() is quite new, a lot of Python code still uses the % operator. However, because this old style of formatting will eventually be removed from the language, str.format() should generally be used. Is this tutorial outdated or this still an issue? It was exuberant wishful thinking. ;) While .format() does have its uses, % is in wide-spread use even among the core-devs. It's not going away any time soon. -- ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Myth Busters: % this old style of formatting will eventually be removed from the language
On 5/21/2013 10:26 PM, Carlos Nepomuceno wrote: I was looking for something else and just found what I think is the place where I was first exposed to the myth[1]: Since str.format() is quite new, a lot of Python code still uses the % operator. However, because this old style of formatting will eventually be removed from the language, str.format() should generally be used. Is this tutorial outdated or this still an issue? [1] http://docs.python.org/2/tutorial/inputoutput.html#old-string-formatting That tutorial is out of date. %-formatting isn't being removed. --Ned. -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 378: Format Specifier for Thousands Separator
On 2013.05.21 21:59, Steven D'Aprano wrote: On Tue, 21 May 2013 14:53:54 -0500, Andrew Berg wrote: On 2013.05.21 14:26, Mark Lawrence wrote: Please stop perpetuating this myth, see http://mail.python.org/pipermail/python-dev/2012-February/116789.html and http://bugs.python.org/issue14123 What myth? The myth that % string formatting is deprecated. It is not deprecated. Skip didn't say that it was deprecated. but no one said % formatting was going away soon. True, but only for the definition no one = all the people who insist that % is deprecated, or soon to be deprecated. Perhaps I missed something, but who is insisting this? What happens in Python 4000 is irrelevant. If somebody is trying to future proof their code for a version that *may never exist*, and if it does exist is likely to be six or eight years away from even starting the design phase, they are wasting their time. It is hard enough to track a moving target, it is impossible to track a target that isn't even a gleam in GvR's eye yet. I think you misunderstand. I'm not suggesting that format() be used simply because % formatting could be deprecated at some unknown time years from now; I was clarifying the status of % formatting. -- CPython 3.3.2 | Windows NT 6.2.9200 / FreeBSD 9.1 -- http://mail.python.org/mailman/listinfo/python-list
RE: PEP 378: Format Specifier for Thousands Separator
From: steve+comp.lang.pyt...@pearwood.info
Subject: Re: PEP 378: Format Specifier for Thousands Separator
Date: Wed, 22 May 2013 03:08:54 +
To: python-list@python.org
[...]
So, the only alternative to have '%,d' % x rendering the thousands
separator output would a C source code modification?
That's one alternative. But the language you would be then running will
no longer be Python.
Another alternative would be to write a pre-processor that parses your
Python source code, extracts any reference to the above, and replaces it
with a call to the appropriate format call. But not only is that a lot of
work for very little gain, but it's also more or less impossible to do in
full generality. And again, what you are running will be something
different than Python, it will be Python plus a pre-processor.
Don't fight the language. You will lose.
Not fighting the language. In fact it's not even a language issue.
All I need is a standard library[1] improvement: %,d! That's all!
Just to put in perspective the performance difference of str.__mod__() and
str.format():
C:\Python27python -m timeit -cv -n1000 '%d'%12345
raw times: 0.386 0.38 0.373
1000 loops, best of 3: 0.0373 usec per loop
C:\Python27python -m timeit -cv -n1000 '{:d}'.format(12345)
raw times: 7.91 7.89 7.98
1000 loops, best of 3: 0.789 usec per loop
C:\Python27python -m timeit -cv -n1000 '{:,d}'.format(12345)
raw times: 8.7 8.67 8.78
1000 loops, best of 3: 0.867 usec per loop
That shows str.format() is 20 times slower than str.__mod__() for a simple
decimal integer literal formatting.
And it's additionally 10% slower if the thousands separator format specifier
(',') is used.
[1] I think that translates to Python source code in 'Objects/stringobject.c'
and maybe 'Objects/unicodeobject.c'
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
Case insensitive dict
I was doing some work with the ldap module and required a ci dict that was case insensitive but case preserving. It turned out the cidict class they implemented was broken with respect to pop, it is inherited and not re implemented to work. Before I set about re-inventing the wheel, anyone know of a working implementation? I noticed twisted has one but it seems to omit pop. Thanks! jlc -- http://mail.python.org/mailman/listinfo/python-list
Re: Case insensitive dict
On Wed, 22 May 2013 03:59:55 +, Joseph L. Casale wrote: I was doing some work with the ldap module and required a ci dict that was case insensitive but case preserving. It turned out the cidict class they implemented was broken with respect to pop, it is inherited and not re implemented to work. Before I set about re-inventing the wheel, anyone know of a working implementation? class my_cidict(ldap.cidict): Fix problems with pop. def pop(self): # insert code here You don't have to re-invent the entire wheel just to fix one broken spoke :-) Other than that, no, I don't know of any case-insensitive but preserving dicts. If you do decide to write one from scratch, please consider releasing it as Open Source (I recommend GPL or MIT licences), either as a module on PyPI or as a recipe on ActiveState. https://pypi.python.org/pypi http://code.activestate.com/recipes/langs/python/ Thank you. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
[issue17973] FAQ entry for: '+=' on a list inside tuple both succeeds and raises an exception
Ronald Oussoren added the comment: I agree that there's probably no good solution here. Catching TypeError would require emitting a lot more byte code, and would change the semantics of augmented assignment, in particular it wouldn't really be an assignment statement anymore (and hides some flow control). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17973 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17140] Provide a more obvious public ThreadPool API
Changes by Tillmann Karras til...@gmail.com: -- nosy: +Tilka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17140 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17683] socket.getsockname() inconsistent return type with AF_UNIX
Roundup Robot added the comment: New changeset c0f2b038fc12 by Charles-François Natali in branch 'default': Issue #17683: socket module: return AF_UNIX addresses in Linux abstract http://hg.python.org/cpython/rev/c0f2b038fc12 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17683 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17683] socket.getsockname() inconsistent return type with AF_UNIX
Charles-François Natali added the comment: Antoine, I need your help :-) http://buildbot.python.org/all/builders/x86 Gentoo Non-Debug 3.x/builds/4311/steps/test/logs/stdio == ERROR: testLinuxAbstractNamespace (test.test_socket.TestLinuxAbstractNamespace) -- Traceback (most recent call last): File /var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/test_socket.py, line 4456, in testLinuxAbstractNamespace s1.bind(address) UnicodeEncodeError: 'ascii' codec can't encode character '\xff' in position 19: ordinal not in range(128) I don't know jack s*** about encoding, but from what I understand, the problem is that the test is passing an invalid ordinal, now that test is passing a string. Should I revert this part of the test (i.e. make the passed address a bytes again)? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17683 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18004] test_list.test_overflow crashes Win64
Anselm Kruis added the comment: I take it you have more than 16GB of RAM? I used a system with 16GB Ram. What happens if you replace sys.maxint with sys.maxsize in test_overflow? The test passes. Both mul and imul raise MemoryError. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18004 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18028] Warnings with -fstrict-aliasing
New submission from Bohuslav Slavek Kabrda: Hi, I'm getting these warnings with -fstrict-aliasing, compiling Python 3.3.2 (compiling with gcc 4.4.7): /builddir/build/BUILD/Python-3.3.2/Python/ceval.c: In function 'PyEval_EvalFrameEx': /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:1006: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:1007: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:1008: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:1009: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:1249: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:1258: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:1372: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2358: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2362: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2377: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2379: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2388: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2390: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2743: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2745: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2896: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2909: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:3035: warning: dereferencing type-punned pointer will break strict-aliasing rules This seems to be quite serious, but I'm not a C expert, so I'd like to know whether this is a false positive or this is actually a dangerous bug. Thanks. -- components: Build messages: 189729 nosy: bkabrda priority: normal severity: normal status: open title: Warnings with -fstrict-aliasing versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18028 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17683] socket.getsockname() inconsistent return type with AF_UNIX
Charles-François Natali added the comment: Hum, IIUC, basically what happens is that the user could - and still can - pass arbitrary bytes as address (which is legtit), but depending on the encoding, getsockaddr() and friends might blow up when decoding it. If that's correct, that's bad, and that would be a good reason to keep bytes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17683 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13146] Writing a pyc file is not atomic
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18028] Warnings with -fstrict-aliasing
Arfrever Frehtes Taifersar Arahesis added the comment: Your Python/ceval.c has custom patches applied. Line 1006 is a comment in unmodified Python/ceval.c in Python 3.3.2. This bug might be caused by your patches. Alternatively it is a bug in GCC 4.4.7. I get 0 warnings for unmodified Python/ceval.c with GCC 4.7.3. -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18028 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6299] pyexpat build failure on Solaris 10 for 2.6.1/2.6.2
Mark Lawrence added the comment: Is this still a problem given that both Python and Solaris have moved on? -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6299 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15392] Create a unittest framework for IDLE
Guilherme Simões added the comment: Now I can apply the patch successfully and everything seems to be working. Thanks, Terry. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15392 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18028] Warnings with -fstrict-aliasing
Bohuslav Slavek Kabrda added the comment: Hmm, you're probably right. The problem seems to be in downstream redefinition of READ_TIMESTAMP. Sorry for the fuzz, closing. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18028 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17917] use PyModule_AddIntMacro() instead of PyModule_AddIntConstant() when applicable
Changes by Charles-François Natali cf.nat...@gmail.com: -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17917 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17914] add os.cpu_count()
Changes by Charles-François Natali cf.nat...@gmail.com: -- stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17914 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18015] python 2.7.5 fails to unpickle namedtuple pickled by 2.7.3 or 2.7.4
Anselm Kruis added the comment: Just for the records: the patch works as expected. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18015 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18015] python 2.7.5 fails to unpickle namedtuple pickled by 2.7.3 or 2.7.4
Changes by Ralf Schmitt python-b...@systemexit.de: -- nosy: +schmir ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18015 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17917] use PyModule_AddIntMacro() instead of PyModule_AddIntConstant() when applicable
Tshepang Lekhonkhobe added the comment: @antoine I don't understand This is a lot of code churn, but it touches code that is unlikely to be modified otherwise, so I guess it's ok.. What does it mean it's okay when it touches on code that's unlikely to be modified? -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17917 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17900] Recursive OrderedDict pickling
Roundup Robot added the comment: New changeset 56f25569ba86 by Serhiy Storchaka in branch 'default': Issue #17900: Allowed pickling of recursive OrderedDicts. Decreased pickled http://hg.python.org/cpython/rev/56f25569ba86 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17917] use PyModule_AddIntMacro() instead of PyModule_AddIntConstant() when applicable
Charles-François Natali added the comment: I don't understand This is a lot of code churn, but it touches code that is unlikely to be modified otherwise, so I guess it's ok.. What does it mean it's okay when it touches on code that's unlikely to be modified? The problem with refactoring is that it can complicate further merges between branches. In this case, the code is nearly never touched, so it's unlikely to be an issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17917 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17900] Recursive OrderedDict pickling
Changes by Serhiy Storchaka storch...@gmail.com: -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18028] Warnings with -fstrict-aliasing
Bohuslav Slavek Kabrda added the comment: Actually, this appears on vanilla Python 3.3 with -DWITH_TSC: Python/ceval.c: In function ‘PyEval_EvalFrameEx’: Python/ceval.c:986:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(inst0); ^ Python/ceval.c:987:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(inst1); ^ Python/ceval.c:988:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(loop0); ^ Python/ceval.c:989:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(loop1); ^ Python/ceval.c:1225:13: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(inst1); ^ Python/ceval.c:1234:9: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(loop0); ^ Python/ceval.c:1348:9: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(inst0); ^ Python/ceval.c:2334:13: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(intr0); ^ Python/ceval.c:2338:13: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(intr1); ^ Python/ceval.c:2353:13: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(intr0); ^ Python/ceval.c:2355:13: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(intr1); ^ Python/ceval.c:2364:13: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(intr0); ^ Python/ceval.c:2366:13: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(intr1); ^ Python/ceval.c:2719:13: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(intr0); ^ Python/ceval.c:2721:13: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(intr1); ^ Python/ceval.c:2872:9: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(inst1); ^ Python/ceval.c:2885:21: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(loop1); ^ Python/ceval.c:3011:9: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(loop1); ^ -- status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18028 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17844] Add link to alternatives for bytes-to-bytes codecs
Serhiy Storchaka added the comment: Not a bad idea. How about implementation? Here is updated patches for 3.x and 2.7. Note that in 2.7 I split codecs table as in 3.x. -- Added file: http://bugs.python.org/file30331/doc_codecs_impl.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17844] Add link to alternatives for bytes-to-bytes codecs
Changes by Serhiy Storchaka storch...@gmail.com: Added file: http://bugs.python.org/file30332/doc_codecs_impl-2.7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17844] Add link to alternatives for bytes-to-bytes codecs
Changes by Serhiy Storchaka storch...@gmail.com: Removed file: http://bugs.python.org/file30013/doc_codecs_impl.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17683] socket.getsockname() inconsistent return type with AF_UNIX
Antoine Pitrou added the comment: Hum, IIUC, basically what happens is that the user could - and still can - pass arbitrary bytes as address (which is legtit), but depending on the encoding, getsockaddr() and friends might blow up when decoding it. Shouldn't the surrogateescape error handler (PEP 383) prevent this? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17683 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17140] Provide a more obvious public ThreadPool API
Richard Oudkerk added the comment: Given that the change could only be made to 3.4, and we already have concurrent.futures.ThreadPoolExecutor, I am not sure there is much point to such a change now. -- nosy: +sbt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17140 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17844] Add link to alternatives for bytes-to-bytes codecs
Nick Coghlan added the comment: I like the idea of splitting the table in 2.7 rather than using a result type column. However, the two intro paragraphs need a bit of work. How does the following sound: 1. Create a new subheading at the same level as the current Standard Encodings heading: Python Specific Encodings 2. Split out rot-13 to its own table in Python 2.7 as well 3. Under the new subheading, have the following text introducing the tables: A number of predefined codecs are specific to Python, so their codec names have no meaning outside Python. These are listed in the tables below based on the expected input and output types (note that while text encodings are the most common use case for codecs, the underlying codec infrastructure supports arbitrary data transforms rather than just text encodings). For asymmetric codecs, the stated purpose describes the encoding direction. The following codecs provide text-to-binary encoding and binary-to-text decoding, similar to the Unicode text encodings. The following codecs provide binary-to-binary encoding and decoding. The following codecs provide text-to-text encoding and decoding. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17140] Provide a more obvious public ThreadPool API
Nick Coghlan added the comment: Thread Pools can be handy when you want to do explicit message passing, rather than the call-and-response model favoured by the futures module. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17140 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12641] Remove -mno-cygwin from distutils
Changes by Paul Moore p.f.mo...@gmail.com: -- nosy: +pmoore ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12641 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17140] Provide a more obvious public ThreadPool API
Richard Oudkerk added the comment: I don't understand what you mean by explicit message passing and call-and-response model. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17140 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17140] Provide a more obvious public ThreadPool API
Nick Coghlan added the comment: Future are explicitly about kicking off a concurrent call and waiting for a reply. They're great for master/slave and client/server models, but not particularly good for actors and other forms of peer-to-peer message passing. For the latter, explicit pools and message queues are still the way to go, and that's why I think a concurrent.pool module may still be useful as a more obvious entry point for the thread pool implementation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17140 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17453] logging.config.fileConfig error
Changes by Łukasz Langa luk...@langa.pl: -- resolution: - works for me stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17453 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17844] Add link to alternatives for bytes-to-bytes codecs
Serhiy Storchaka added the comment:
However, the two intro paragraphs need a bit of work.
Yes, it's a help which I needed. Thank you.
However your wording is not entirely correct. In 2.7 binary-to-binary codecs
and rot-13 works with Unicode strings (only ascii-compatible) as with bytes
strings.
u'Python'.encode('base64')
'UHl0aG9u\n'
u'UHl0aG9u'.decode('base64')
'Python'
u'Python\u20ac'.encode('base64')
Traceback (most recent call last):
File stdin, line 1, in module
File /home/serhiy/py/cpython-2.7/Lib/encodings/base64_codec.py, line 24, in
base64_encode
output = base64.encodestring(input)
File /home/serhiy/py/cpython-2.7/Lib/base64.py, line 315, in encodestring
pieces.append(binascii.b2a_base64(chunk))
UnicodeEncodeError: 'ascii' codec can't encode character u'\u20ac' in position
6: ordinal not in range(128)
Rot-13 works as common text-to-binary encoding (encode returns str, decode
returns unicode).
u'Python'.encode('rot13')
'Clguba'
u'Python'.decode('rot13')
u'Clguba'
'Python'.encode('rot13')
'Clguba'
'Python'.decode('rot13')
u'Clguba'
u'Python\u20ac'.encode('rot13')
Traceback (most recent call last):
File stdin, line 1, in module
File /home/serhiy/py/cpython-2.7/Lib/encodings/rot_13.py, line 17, in encode
return codecs.charmap_encode(input,errors,encoding_map)
UnicodeEncodeError: 'charmap' codec can't encode character u'\u20ac' in
position 6: character maps to undefined
u'Python\u20ac'.decode('rot13')
Traceback (most recent call last):
File stdin, line 1, in module
File /home/serhiy/py/cpython-2.7/Lib/encodings/rot_13.py, line 20, in decode
return codecs.charmap_decode(input,errors,decoding_map)
UnicodeEncodeError: 'ascii' codec can't encode character u'\u20ac' in position
6: ordinal not in range(128)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17844
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
Changes by Ken Giusti kgiu...@gmail.com: -- nosy: +Ken.Giusti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8240 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12641] Remove -mno-cygwin from distutils
Oscar Benjamin added the comment: I'd really like to get a resolution on this issue so I've tried to gather some more information about this problem by asking some questions in the mingw-users mailing list. The resulting thread can be found here: http://comments.gmane.org/gmane.comp.gnu.mingw.user/42092 This issue concerns users of distutils --compiler=mingw32 mode. Normally this is used to build with mingw gcc in which case it is currently broken because of -mno-cygwin. It has been suggested above that some may be using it to build with cygwin's gcc. The -mno-cygwin option is there for those using cygwin's gcc. To summarise the points (see the thread on mingw-users for more info): 1) -mno-cygwin has never had a meaningful effect in mingw. 2) -mno-cygwin produces an error in recent (~2011 onwards) mingw releases and will do for all future releases. This prevents distutils from building extensions with mingw. 3) -mno-cygwin only ever had a meaningful effect for cygwin's gcc 3.x where it could be used to build binaries that did not depend in cygwin.dll. 4) -mno-cygwin was always considered an experimental feature and its use is discouraged. 5) -mno-cygwin was removed from cygwin's gcc in the transition from 3.x to 4.x without any deprecation period (as it was an experimental feature). In gcc 4.x it produces an error preventing build. 6) The recommended way to replace the -mno-cygwin option is either to use mingw or to use cygwin's cross-compilers. So there are two types of breakage affected by -mno-cygwin: A: Anyone trying to use recent and future mingw versions to build extensions with distutils in the way that is described in the distutils docs. For this group distutils has been broken for 2 years and will continue to be until the -mno-cygwin option is removed. B: Anyone who is using distutils with --compiler=mingw32 but using cygwin's gcc 3.x instead of mingw's gcc to build an extension for a non-cygwin Python. For this group removing the -mno-cygwin option would result in unusable extension modules. (the resulting .pyd requires cygwin.dll but is to be used in a non-cygwin Python). Firstly, note that users in group B must surely be a group that diminishes with time since they are using the legacy gcc 3.x cygwin compiler. Similarly, since neither of mingw or cygwin will ever bring back -mno-cygwin users in group A will only increase with time. (I am such a user and have been manually removing all reference to -mno-cygwin from distutils for 2 years now.) This means that the balance of breakage will only move towards group A over time. Secondly, any users in group B will suffer the same problem as users in group A if they try to use gcc 4.x. However this has not been reported on the tracker (I read through all matches in a search for '-mno-cygwin'). I think this serves as an indication of how many people are actually using this setup. Thirdly, the -mno-cygwin option is a now-abandoned, experimental feature of a legacy compiler. Its creators did not feel the need to give it a deprecation period and its use is discouraged by both mingw and cygwin. Bringing these points together: not removing -mno-cygwin from distutils trades the possible breakage for possibly non-existent users of the obscure, legacy, and generally considered broken setup B against the definite, known breakage for users of the appropriate documented setup A. I think this should be enough to say that the fix for the next Python version should simply remove all reference to '-mno-cygwin' as I have been doing for 2 years now without problem. The only users who can be adversely affected by this are those in group B who decide to upgrade to non-cygwin Python 3.4 (while still using an ancient cygwin gcc to build extensions). The suggested fix can be either to use mingw or to setup the cross-compilers in their cygwin installation. For Python 2.7, 3.2 and 3.3 I think that this should be considered a bug that can be fixed in a bugfix release. However in that case it may be considered inappropriate to risk the small possibility of users in group B experiencing breakage. Since such users must be using cygwin's gcc 3.x, I propose that distutils check the gcc version and only add '-mno-cygwin' if the major version is 3. This will not adversely affect users in group B and will fix the problem for users in group A. Users in group B who attempt to use gcc 4.x will find that they get a different error message (at import time instead of build time) but that their setup will still be just as broken as it was before this change. Thanks, Oscar -- nosy: +oscarbenjamin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12641 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
