EuroPython 2015: Submitted Proposal
The EuroPython Society (EPS) is happy to announce that we have received the amended proposal from the ACPySS team in Spain (http://www.pyss.org/) to hold EuroPython 2015 in Bilbao, Spain. We had been discussing questions with them in the last couple of days. On-site Team Proposal - Following the CFP process, we are now publishing the redacted version of the proposal, which has all the confidential information removed: ACPySS proposal for EuroPython 2015 in Bilbao (41MB PDF) https://www.dropbox.com/s/bx19vj8xvwd8wc9/Proposal-Bilbao-final.pdf?dl=1 The EPS board will now do a final review and announce the decision in the next two weeks (2014-12-26 latest). Please send your feedback - We would like to encourage feedback from the EuroPython and Python community regarding the proposal. Please send your emails to the europython-improve mailing list (you will have to sign up to that list before being able to post there): https://mail.python.org/mailman/listinfo/europython-improve Thank you, -- EuroPython Society http://www.europython-society.org/ -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
ANN: PROVABLEPRIME 1.1.2 released
PROVABLEPRIME Version 1.1.2, Generation of provable primes with Maurer's algorithm, with illustrative coding of RSA encryption (with authentication) and digital signature for sequences of fixed-sized plaintext blocks and RSA pseudo-random bit generation, is available at: http://s13.zetaboards.com/Crypto/topic/7234475/1/ M. K. Shen -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
ANN: PREFIXCODING 2.0 released
PREFIXCODING Version 2.0, an encryption scheme (with authentication) with pseudo-random prefix codes substitution and pseudo-random transposition is available at: http://s13.zetaboards.com/Crypto/topic/7164646/1/. M. K. Shen -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
[ANN] pyspread 0.4
pyspread 0.4 Pyspread 0.4 is released. In this release, rendering has switched to Cairo, which enhances quality and performance. Grid content can now be exported into high quality PDF and SVG files. Cells can now display SVG images and text with markups. The nn function now removes None from lists, tuples, etc. About pyspread == Pyspread is a non-traditional spreadsheet application that is based on and written in the programming language Python. The goal of pyspread is to be the most pythonic spreadsheet application. Pyspread is free software. It is released under the GPL v3. Project website: http://manns.github.com/pyspread/ Download page: https://pypi.python.org/pypi/pyspread Enjoy Martin -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Re: Portable code: __import__ demands different string types between 2 and 3
On Sun, Dec 14, 2014 at 11:29 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
I'm slowly learning about making Python code that will run under both
Python 2 (version 2.6 or above) and Python 3 (version 3.2 or above).
This entails, I believe, the admonition to ensure text literals are
Unicode by default::
from __future__ import unicode_literals
Ordinarily, for 2.x/3.3+ code I would suggest not doing this --
instead, b'...' for bytes, u'...' for unicode, and '...' for native
string type (bytes on 2.x, unicode on 3.x). This is the main benefit
of the u'...' syntax addition.
For 3.2, you'll have to do b'...' for bytes, '...' for unicode, and
str('...') for platform-specific strings (bytes on 2.x, unicode on
3.x). It is in good taste to make an alias of str so it's less
confusing, e.g. native_str = str.
So for example, it's __import__(str(foo)), and getattr(foo, str(bar), baz).
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
Re: is_whatever_you_are_testing_for as method or property?
On 13 December 2014 at 12:24, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Mateusz Loskot wrote: On 12 December 2014 at 12:26, Chris Angelico ros...@gmail.com wrote: On Fri, Dec 12, 2014 at 10:21 PM, Mateusz Loskot mate...@loskot.net wrote: I've got several cases which are not obvious to me. For instance, class Foo has a boolean attribute, read-write, which I see a couple of realisations for possible: [...] I mentioned, setting the new value involves more changes to Foo() instance, so i's not possible to capture it with just an assignment. Hence, the discussion between property vs method. If the calculation is cheap and fast and feels like getting/setting an attribute, then use property. If the calculation is expensive, or might fail, then use explicit getter/setter methods. I'm afraid that there is no objective way to tell when something feels like an attribute. That depends partly on the class you are dealing with, and partly on personal taste. That confirms my now updated, thanks to this thread, understanding of that issue. Thanks all! Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- https://mail.python.org/mailman/listinfo/python-list
Re: ** in python
In article mailman.16217.1416793733.18130.python-l...@python.org,
Skip Montanaro skip.montan...@gmail.com wrote:
-=-=-=-=-=-
I want to add one more thing to the other responses. People new to Python
often seem unaware that being an interpreted language, often the best way
to figure something out is to simply try it at the interpreter prompt. The
OP saw var ** 2 in done code. The most obvious thing to me would have
been to type
var = 42
var ** 2
and see what happened. It's unlikely to trigger a nuclear meltdown, or even
crash the interpreter.
Skip
-=-=-=-=-=-
[Alternative: text/html]
-=-=-=-=-=-
With some perseverance, you can ask the interpreter what `` ** ''
does:
help(**)
syntax error
maybe so?
help('**')
Indeed, a whole description.
help(var)
help(42)
also work.
Come on, guys and dolls! Your advice to a newbies is soso,
if in this kind of answer, the help facilitiy is not
mentionned.
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spearc.xs4all.nl =n http://home.hccnet.nl/a.w.m.van.der.horst
--
https://mail.python.org/mailman/listinfo/python-list
Re: encoding name mappings in codecs.py with email/charset.py
I played around with changing the names in the aliases.py and locale.py
files (from iso8859 to iso-88559), but this broke mailman.
I ended up changing the charset.py file
input_charset = codecs.lookup(input_charset).name
except LookupError:
pass
if (input_charset == 'iso8859-7'):
input_charset = 'iso-8859-15
if (input_charset == 'iso8859-15'):
input_charset = 'iso-8859-7'
if (input_charset == 'iso8859-1'):
input_charset = 'iso-8859-1'
This seems to work for now.
I really wonder why I'm the only one with this problem. This should affect
all Mailman users with member on MS Exchange 2010 (at least) servers.
Exchange produces
CAT.InvalidContent.Exception: InvalidCharsetException, Character set name
(iso8859-7) is invalid or not installed.; cannot handle content of message
with...
Thanks gst for the input
sk
On Sun, Dec 14, 2014 at 9:53 PM, gst g.sta...@gmail.com wrote:
Le dimanche 14 décembre 2014 14:10:22 UTC-5, Stefanos Karasavvidis a
écrit :
thanks for replying gst.
I've thought already of patching the Charset class, but hoped for a
cleaner solution.
This ALIASES dict has already all the iso names *with* a dash. So it
must get striped somewhere else.
not on my side, modifying this dict with the missing key-value apparently
does what you want also :
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
Type copyright, credits or license() for more information.
import email.charset
email.charset.ALIASES
{'latin-8': 'iso-8859-14', 'latin-9': 'iso-8859-15', 'latin-2':
'iso-8859-2', 'latin-3': 'iso-8859-3', 'latin-1': 'iso-8859-1', 'latin-6':
'iso-8859-10', 'latin-7': 'iso-8859-13', 'latin-4': 'iso-8859-4',
'latin-5': 'iso-8859-9', 'euc_jp': 'euc-jp', 'latin-10': 'iso-8859-16',
'ascii': 'us-ascii', 'latin_10': 'iso-8859-16', 'latin_1': 'iso-8859-1',
'latin_2': 'iso-8859-2', 'latin_3': 'iso-8859-3', 'latin_4': 'iso-8859-4',
'latin_5': 'iso-8859-9', 'latin_6': 'iso-8859-10', 'latin_7':
'iso-8859-13', 'latin_8': 'iso-8859-14', 'latin_9': 'iso-8859-15', 'cp949':
'ks_c_5601-1987', 'euc_kr': 'euc-kr'}
for i in range(1, 16):
c = 'iso-8859-' + str(i)
email.charset.ALIASES[c] = c
iso7 = email.charset.Charset('iso-8859-7')
iso7
iso-8859-7
str(iso7)
'iso-8859-7'
regards,
gst.
sk
On Sun, Dec 14, 2014 at 7:21 PM, gst g.st...@gmail.com wrote:
Le vendredi 12 décembre 2014 04:21:14 UTC-5, Stefanos Karasavvidis a
écrit :
I've hit a wall with mailman which seems to be caused by pyhon's
character encoding names.
I've narrowed the problem down to the email/charset.py file. Basically
the following happens:
Hi,
it's all in the email.charset.ALIASES dict.
you could also simply patch the __str__ method of Charset :
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
Type copyright, credits or license() for more information.
import email.charset
c = email.charset.Charset('iso-8859-7')
str(c)
'iso8859-7'
old = email.charset.Charset.__str__
def patched(self):
r = old(self)
if r.startswith('iso'):
return 'iso-' + r[3:]
return r
email.charset.Charset.__str__ = patched
str(c)
'iso-8859-7'
regards,
gst.
--
https://mail.python.org/mailman/listinfo/python-list
--
==
Stefanos Karasavvidis, Electronic Computer Engineer, M.Sc.
e-mail: s...@isc.tuc.gr, Tel.: (+30) 2821037508, Fax: (+30) 2821037520
Technical University of Crete, Campus, Building A1
--
https://mail.python.org/mailman/listinfo/python-list
--
==
Stefanos Karasavvidis, Electronic Computer Engineer, M.Sc.
s...@isc.tuc.gre-mail: s...@isc.tuc.gr, Tel.: (+30) 2821037508, Fax: (+30)
2821037520
Technical University of Crete, Campus, Building A1
--
https://mail.python.org/mailman/listinfo/python-list
Re: ** in python
Albert van der Horst wrote:
With some perseverance, you can ask the interpreter what `` ** ''
does:
help(**)
syntax error
maybe so?
help('**')
Indeed, a whole description.
Yes! Well spotted!
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Portable code: __import__ demands different string types between 2 and 3
Ben Finney wrote: Howdy all, What should I do, in a world where all text literals are Unicode by default, to make ‘__import__’ work in both Python 2 and 3? One approach I frequently use is a conditional import. Off the top of my head, I'd do something like this: try: import builtins # Python 3.x. except ImportError: # We're probably running Python 2.x. import __builtin__ as builtins # Untested, just to give you an idea of what I mean. try: _ = __import__(sys, fromlist=[version]) except TypeError: # Shadow the built-in with a patched version. def __import__(*args, **kwargs): if fromlist in kwargs: kwargs[fromlist] = [str(name) for name in kwargs[fromlist]] return builtins.__import__(*args, **kwargs) If you're really brave, you can even monkey-patch builtins with your own version. Obviously you still need to keep the old version somewhere. A closure would be perfect for that: # Again, untested. def patch_import(original_import=__import__): def __import__(*args, **kwargs): if fromlist in kwargs: kwargs[fromlist] = [str(name) for name in kwargs[fromlist]] return original_import(*args, **kwargs) builtins.__import__ = __import__ Monkey-patching builtins.__import__ is one of the few not-completely-frowned-upon uses of monkey-patching. Perhaps a better approach might be to eschew the use of __import__ and see whether the functions in imputil (deprecated) or importlib do what you need. https://docs.python.org/2/library/imputil.html https://docs.python.org/3/library/importlib.html Aside: __import__ is not recommended for user code. Direct use of __import__() is also discouraged in favor of importlib.import_module(). https://docs.python.org/3/library/functions.html#__import__ -- Steven -- https://mail.python.org/mailman/listinfo/python-list
ANN: Benchmarker 4.0.0 released - small but awesome benchmark utility
I released Benchmarker ver 4.0.0 http://pypi.python.org/pypi/Benchmarker/ http://pythonhosted.org/Benchmarker/ Benchmarker is a small utility to benchmark your code. *NOTICE* This release doesn't have compatibility with ver 3.x. Installation $ sudo pip install Benchmarker Example --- example.py:: from benchmarker import Benchmarker with Benchmarker(1000*1000, width=20) as bench: s1, s2, s3, s4, s5 = Haruhi, Mikuru, Yuki, Itsuki, Kyon @bench(None) def _(bm): for _ in bm: ## empty loop pass @bench(concat) def _(bm): for _ in bm: s = s1 + s2 + s3 + s4 + s5 @bench(join) def _(bm): for _ in bm: s = .join((s1, s2, s3, s4, s5)) @bench(format) def _(bm): for _ in bm: s = %s%s%s%s%s % (s1, s2, s3, s4, s5) Output example:: $ python example.py -h # show help message. $ python example.py # or python example.py -n 100 ## benchmarker: release 4.0.0 (for python) ## python version: 3.4.1 ## python compiler: GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.51) ## python platform: Darwin-14.0.0-x86_64-i386-64bit ## python executable: /usr/local/bin/python ## cpu model: Intel(R) Core(TM) i7-4650U CPU @ 1.70GHz ## parameters: loop=100, cycle=1, extra=0 ##real(total= user+ sys) (Empty) 0.03350.03000.03000. concat 0.41920.42000.41000.0100 join0.36740.37000.37000. format 0.47650.46000.46000. ## Rankingreal join0.3674 (100.0) concat 0.4192 ( 87.6) ** format 0.4765 ( 77.1) *** ## Matrix real[01][02][03] [01] join 0.3674 100.0 114.1 129.7 [02] concat 0.419287.6 100.0 113.7 [03] format 0.476577.188.0 100.0 Notice that empty loop times (real, user, sys and total) are subtracted from other benchmark times automatically. For example:: === benchmark labelreal (second) --- join 0.3674 (= 0.4009 - 0.0335) concat 0.4192 (= 0.4527 - 0.0335) format 0.4765 (= 0.5100 - 0.0335) === See http://pythonhosted.org/Benchmarker/ for details. Have fun! -- regards, makoto kuwata -- https://mail.python.org/mailman/listinfo/python-list
Python {executable templates from XSLT, code generation tool}
Hi, I'm searching a tool to translate an xsl file to executable python code. I know how to execute xslt with python. What I want is to process my xslt rules *in* python. Example : xsl:when test=gender = 'Male' Mr /xsl:when xsl:otherwise Mrs /xsl:otherwise I would like it to be translated in a python test statement. Does anyone know something like this ? Or at least a code generation tool ? I read about Cog and might use it. Jbb -- https://mail.python.org/mailman/listinfo/python-list
Re: Portable code: __import__ demands different string types between 2 and 3
On 12/14/2014 11:29 PM, Ben Finney wrote:
This entails, I believe, the admonition to ensure text literals are
Unicode by default::
from __future__ import unicode_literals
and to specify bytes literals explicitly with ‘b'wibble'’ if needed.
For some scripts this works great (I have some), and for some it does not (I
have some of those, too).
The ‘__import__’ built-in function, though, is tripping up.
One work-around I have used is:
if isinstance(some_var, bytes):
some_var = some_var.decode('ascii')
# at this point some_var is unicode in both Pythons
--
~Ethan~
signature.asc
Description: OpenPGP digital signature
--
https://mail.python.org/mailman/listinfo/python-list
RE: Classes - converting external function to class's method.
Again Thanks for your help. I saw that there was a debate about namespace nature. That is what a book says about it(Learning Python 5 Ed. By Mark Lutz): * Classes and Instances Although they are technically two separate object types in the Python model, the classes and instances we put in these trees are almost identical—each type’s main purpose is to serve as another kind of namespace—a package of variables, and a place where we can attach attributes. If classes and instances therefore sound like modules, they should; however, the objects in class trees also have automatically searched links to other namespace objects, and classes correspond to statements, not entire files. Customization via inheritance More generally, classes can build up namespace hierarchies, which define names to be used by objects created from classes in the hierarchy. This supports multiple customizable behaviors more directly than other tools. ...classes live in modules and are namespaces as well, but they add an extra component to attribute lookup called inheritance search. In fact, classes have just three primary distinctions. At a base level, they are mostly just namespaces, much like the modules we studied in Part V. Unlike modules, though, classes also have support for generating multiple objects, for namespace inheritance, and for operator overloading. I'm not pretending to be a smartass here, but as I can understand from the context: Classes are namespaces, but they also have an additional capabilities. BR, Ivan -Original Message- From: Python-list [mailto:python-list- bounces+webmailgroups=gmail@python.org] On Behalf Of Steven D'Aprano Sent: Monday, December 15, 2014 04:01 To: python-list@python.org Subject: Re: Classes - converting external function to class's method. Thomas 'PointedEars' Lahn wrote: Ivan Evstegneev wrote: I have stuck a bit with this example(took this one from the book). Here are a description steps of what I've done till now: Step 1 - creating an empty namespace: class rec: pass IMHO that is not actually creating a namespace; it is just declaring/defining an empty class. And classes are namespaces. As are instances. One clue is the fact that we use exactly the same syntax for accessing names in a namespace regardless of whether the namespace is a package, a module, a class or an instance: import collections.abc # a package namespace math.sin # a module namespace OrderedDict.fromkeys # a class namespace mystring.upper # an instance namespace I call it a clue rather than definitive proof because the syntax is not quite the same for all namespaces. Local and global variables also exist in namespaces, but you don't use dotted notation for them. Another clue is that most of these are implemented by using a __dict__ to store the name:value mapping. Again, that's not universal: instances can optionally use __slots__ instead of __dict__ and packages use the file system. Apart from packages, one can use getattr(), setattr() and delattr() on all of these objects (modules, classes and instances) to manipulate their attributes. Wikipedia says: In general, a namespace is a container for a set of identifiers (also known as symbols, names). https://en.wikipedia.org/wiki/Namespace and that applies to packages, modules, classes, and instances. Last but not least, another clue: in some languages, such as Java, what Python calls attributes are known as *variables*. So per-instance members are called instance variables, per-class members are sometimes called class variables (although not in Java, where I believe they are known as static variables for technical reasons). Personally, I don't like that terminology, but I do recognise that it does reflect a certain connection between names in local/global/instance/class namespaces. BTW, the recommended Python 3.x way is class Rec (object): pass I think you mean Python 2 rather than 3. In Python 2, we have legacy old style or classic classes, and new style classes which inherit from object. In Python 3, classic classes are gone, and inheriting from object is optional. (whereas “pass” is a placeholder statement, a bit like the yada-yada operator of Python) and you should start class identifiers uppercase (therefore, “Rec” instead) in order to avoid name collisions with built-in class identifiers (“str”, “int” etc.) and make it easier to tell apart instantiations from function/method calls. Agreed! It is good practice to name classes with initial capital letter, and instances in all lowercase. If you call that method as the method of a class (object), you need to pass an argument for the first parameter because you have made it positional, not optional
[ANN] pyspread 0.4
pyspread 0.4 Pyspread 0.4 is released. In this release, rendering has switched to Cairo, which enhances quality and performance. Grid content can now be exported into high quality PDF and SVG files. Cells can now display SVG images and text with markups. The nn function now removes None from lists, tuples, etc. About pyspread == Pyspread is a non-traditional spreadsheet application that is based on and written in the programming language Python. The goal of pyspread is to be the most pythonic spreadsheet application. Pyspread is free software. It is released under the GPL v3. Project website: http://manns.github.com/pyspread/ Download page: https://pypi.python.org/pypi/pyspread Enjoy Martin -- https://mail.python.org/mailman/listinfo/python-list
Portable code: ‘from __future__ import unicode_literals’ a good idea? (was: Portable code: __import__ demands different string types between 2 and 3)
Devin Jeanpierre jeanpierr...@gmail.com writes: On Sun, Dec 14, 2014 at 11:29 PM, Ben Finney ben+pyt...@benfinney.id.au wrote: from __future__ import unicode_literals Ordinarily, for 2.x/3.3+ code I would suggest not doing this -- instead, b'...' for bytes, u'...' for unicode, and '...' for native string type (bytes on 2.x, unicode on 3.x). This is the main benefit of the u'...' syntax addition. That latter point would seemingly also apply to ‘from __future__ import unicode_literals’, so is moot in this context. As for the advice to avoid such a declaration, you're arguing against the official guide for porting Python 2 code to 2-and-3 compatible code: For text you should either use the from __future__ import unicode_literals statement or add a u prefix to the text literal. URL:https://docs.python.org/3.4/howto/pyporting.html#text-versus-binary-data So, the declarative import is specifically recommended. You'll need to present a case for why I shouldn't follow that recommendation. -- \ “I disapprove of what you say, but I will defend to the death | `\ your right to say it.” —Evelyn Beatrice Hall, _The Friends of | _o__) Voltaire_, 1906 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Portable code: ‘from __future__ import unicode_literals’ a good idea? (was: Portable code: __import__ demands different string types between 2 and 3)
On Mon, Dec 15, 2014 at 4:42 PM, Ben Finney ben+pyt...@benfinney.id.au wrote: Devin Jeanpierre jeanpierr...@gmail.com writes: On Sun, Dec 14, 2014 at 11:29 PM, Ben Finney ben+pyt...@benfinney.id.au wrote: from __future__ import unicode_literals Ordinarily, for 2.x/3.3+ code I would suggest not doing this -- instead, b'...' for bytes, u'...' for unicode, and '...' for native string type (bytes on 2.x, unicode on 3.x). This is the main benefit of the u'...' syntax addition. That latter point would seemingly also apply to ‘from __future__ import unicode_literals’, so is moot in this context. As for the advice to avoid such a declaration, you're arguing against the official guide for porting Python 2 code to 2-and-3 compatible code: For text you should either use the from __future__ import unicode_literals statement or add a u prefix to the text literal. URL:https://docs.python.org/3.4/howto/pyporting.html#text-versus-binary-data So, the declarative import is specifically recommended. You'll need to present a case for why I shouldn't follow that recommendation. All the doc is saying there is to use unicode for text, in a way that works in both 2.x and 3.x. I am saying that the unicode_literals import is not necessarily the best way to do so. Python has three categories of strings: things that should be bytes in 2.x and 3.x, things that should be unicode in 2.x and 3.x, and things that should be bytes on 2.x and unicode on 3.x. The last category applies mostly to identifiers -- the strings you pass to functions like getattr or __import__, and the strings that are valid keys in **kwargs, and so on. You need a way to represent the last kind of string, whether it's unadorned ... literals, or function calls like identifier_string(...). If you can solve that, you are good. The official porting guide offers no advice. -- Devin -- https://mail.python.org/mailman/listinfo/python-list
Re: Portable code: ‘from __future__ import unicode_literals’ a good idea?
On 12/15/14 7:42 PM, Ben Finney wrote: As for the advice to avoid such a declaration, you're arguing against the official guide for porting Python 2 code to 2-and-3 compatible code: For text you should either use the from __future__ import unicode_literals statement or add a u prefix to the text literal. URL:https://docs.python.org/3.4/howto/pyporting.html#text-versus-binary-data So, the declarative import is specifically recommended. You'll need to present a case for why I shouldn't follow that recommendation. What's wrong with this part of the recommendation?: or add a u prefix to the text literal. Also, keep in mind, these recommendations are not infallible. They are sometimes written before there's been broad experience with the solution. Your use of __import__ puts you in a tiny minority of programs, so the recommendation that's good for 99% of code may not work for you. Be flexible. Do what works. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Portable code: __import__ demands different string types between 2 and 3
Ethan Furman et...@stoneleaf.us writes:
On 12/14/2014 11:29 PM, Ben Finney wrote:
The ‘__import__’ built-in function, though, is tripping up.
One work-around I have used is:
if isinstance(some_var, bytes):
some_var = some_var.decode('ascii')
# at this point some_var is unicode in both Pythons
That's not the issue at all. I know how to declare a literal such that
it is Unicode in Python 2 and Python 3 (that's what the ‘from __future__
import unicode_literals’ does).
Rather, the problem is ‘__import__’ having incompatible expectations:
the ‘fromlist’ parameter's items must be bytes in Python 2, and must be
Unicode in Python 3.
The same parameter value can't satisfy both those requirements in a
single 2-and-3 compatible code base, without either using the
bytes-and-text ambiguity of ‘str’, or some kludge over-riding a simple
‘__import__’ call. Both of those are ugly and make for buggy code.
I'm increasingly of the opinion this is a subtle bug in ‘__import__’
that should be fixed instead of worked around. But it will likely be
rejected because the documentation advises against using ‘__import__’.
Bah.
--
\ “Try adding “as long as you don't breach the terms of service – |
`\ according to our sole judgement” to the end of any cloud |
_o__) computing pitch.” —Simon Phipps, 2010-12-11 |
Ben Finney
--
https://mail.python.org/mailman/listinfo/python-list
Re: Portable code: __import__ demands different string types between 2 and 3
On 12/15/2014 05:36 PM, Ben Finney wrote: That's not the issue at all. I know how to declare a literal such that it is Unicode in Python 2 and Python 3 (that's what the ‘from __future__ import unicode_literals’ does). Rather, the problem is ‘__import__’ having incompatible expectations: the ‘fromlist’ parameter's items must be bytes in Python 2, and must be Unicode in Python 3. Ah. Well, then you do not want the `unicode_literals` import or it won't be bytes in Python 2 (as I'm sure you know). The same parameter value can't satisfy both those requirements in a single 2-and-3 compatible code base, without either using the bytes-and-text ambiguity of ‘str’, or some kludge over-riding a simple ‘__import__’ call. Both of those are ugly and make for buggy code. If this is for a large(ish) application, make one module with stuff that needs the ambiguity to work correctly. Comment the heck out of it. ;) I'm increasingly of the opinion this is a subtle bug in ‘__import__’ that should be fixed instead of worked around. Of course. But you'll still need to work around it for previous versions, unless you can say you only support 2.7.10+ (maybe 2.7.9+ if it gets fixed quick enough). But it will likely be rejected because the documentation advises against using ‘__import__’. Functions that should accept str but barf on unicode have a tendency to get fixed. -- ~Ethan~ signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Portable code: ‘from __future__ import unicode_literals’ a good idea?
Ned Batchelder n...@nedbatchelder.com writes: On 12/15/14 7:42 PM, Ben Finney wrote: As for the advice to avoid such a declaration, you're arguing against the official guide for porting Python 2 code to 2-and-3 compatible code: For text you should either use the from __future__ import unicode_literals statement or add a u prefix to the text literal. URL:https://docs.python.org/3.4/howto/pyporting.html#text-versus-binary-data So, the declarative import is specifically recommended. You'll need to present a case for why I shouldn't follow that recommendation. What's wrong with this part of the recommendation?: or add a u prefix to the text literal. Who's saying there's anything wrong with that? Not I. My question is, what's wrong with the first part such that Devin recommends against it? Also, keep in mind, these recommendations are not infallible. Yes, Devin clears up in a later message that the official guide provides no advice for the case where an API needs ‘bytes’ in Python 2 but Unicode in Python 3. Be flexible. Do what works. Good advice, but nothing different from what I'm already trying to do. -- \“[R]ightful liberty is unobstructed action, according to our | `\will, within limits drawn around us by the equal rights of | _o__) others.” —Thomas Jefferson, 1819 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Portable code: __import__ demands different string types between 2 and 3
Ben Finney wrote: I'm increasingly of the opinion this is a subtle bug in ‘__import__’ that should be fixed instead of worked around. But it will likely be rejected because the documentation advises against using ‘__import__’. Bah. I think its worth raising an issue on the bug tracker and see what the core devs think. If you don't have and won't open an account on the tracker, if you can come up with a minimal example that demonstrates the issue, I'll open an issue for you. (But I'd rather you did it yourself :-) -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Portable code: __import__ demands different string types between 2 and 3
Ethan Furman et...@stoneleaf.us writes: On 12/15/2014 05:36 PM, Ben Finney wrote: I'm increasingly of the opinion this is a subtle bug in ‘__import__’ that should be fixed instead of worked around. And other people agree: URL:https://bugs.python.org/issue21720. Of course. But you'll still need to work around it for previous versions, unless you can say you only support 2.7.10+ (maybe 2.7.9+ if it gets fixed quick enough). If I can eventually drop the kludge by dropping support for Python 2.7 at some future point (instead of waiting until I can drop Python 3), that would still be an improvement. Functions that should accept str but barf on unicode have a tendency to get fixed. I hope you're right. The bug report currently focusses on improving the error message only. -- \ “They who can give up essential liberty to obtain a little | `\temporary safety, deserve neither liberty nor safety.” | _o__) —Benjamin Franklin, 1775-02-17 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Portable code: __import__ demands different string types between 2 and 3
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes: If you don't have and won't open an account on the tracker, if you can come up with a minimal example that demonstrates the issue, I'll open an issue for you. (But I'd rather you did it yourself :-) Thank you for the offer. Fortunately, the Python bug tracker does not require me to maintain credentials for that site (I can use any OpenID), so I've got an account there. -- \ “Our task must be to free ourselves from our prison by widening | `\our circle of compassion to embrace all humanity and the whole | _o__) of nature in its beauty.” —Albert Einstein | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Neat little programming puzzle
This was a problem posed to me, which I solved in Python. I thought it was neat and enjoyed the exercise of working through it; feel free to ignore. For people looking for little projects to practice their skills with (or a simple distraction), read on. You have a triangle of numbers such that each row has 1 more number than the row before it, like so: 1 32 861 510 15 2 The task is to find the maximum possible sum through the triangle that you can compute by adding numbers that are adjacent to the value chosen in the row above. In this simple example, the solution is 1+3+6+15=25. As the number of rows increases, the possible paths through the triangle grows exponentially (and it's not enough to just look at the max value in each row, since they may not be part of the optimum pathway, like the '8' in row 3 of the above example). The challenge is to write a program to compute the sum of https://gist.github.com/swails/17ef52f3084df708816d. I liked this problem because naive solutions scale as O(2^N), begging for a more efficient approach. Have fun, Jason -- https://mail.python.org/mailman/listinfo/python-list
Re: Neat little programming puzzle
On Mon, Dec 15, 2014 at 10:46 PM, Jason Swails jason.swa...@gmail.com wrote: This was a problem posed to me, which I solved in Python. I thought it was neat and enjoyed the exercise of working through it; feel free to ignore. For people looking for little projects to practice their skills with (or a simple distraction), read on. You have a triangle of numbers such that each row has 1 more number than the row before it, like so: 1 32 861 510 15 2 The task is to find the maximum possible sum through the triangle that you can compute by adding numbers that are adjacent to the value chosen in the row above. In this simple example, the solution is 1+3+6+15=25. As the number of rows increases, the possible paths through the triangle grows exponentially (and it's not enough to just look at the max value in each row, since they may not be part of the optimum pathway, like the '8' in row 3 of the above example). The challenge is to write a program to compute the sum of https://gist.github.com/swails/17ef52f3084df708816d. I liked this problem because naive solutions scale as O(2^N), begging for a more efficient approach. This pretty much screams for a dynamic programming solution. ikelly@hephaestus ~ $ cat triangle_sum.py #!/usr/bin/env python3 from urllib.request import urlopen import sys def main(): triangle = read_triangle(urlopen(sys.argv[1])) print(Maximum possible sum is, triangle_sum(triangle)) def read_triangle(from_file): rows = [] for line in from_file: values = [int(x) for x in line.strip().split()] rows.append(values) if len(values) != len(rows): raise ValueError(Invalid triangle input) return rows def triangle_sum(triangle): dp_row = triangle[-1] for row in reversed(triangle[:-1]): dp_row = [row[i] + max(dp_row[i], dp_row[i+1]) for i in range(len(row))] return dp_row[0] if __name__ == __main__: main() ikelly@hephaestus ~ $ time python3 triangle_sum.py https://gist.githubusercontent.com/swails/17ef52f3084df708816d/raw/aae1c494e69f0b3dad1eb6ea818f8f36d05be7a3/gistfile1.txt Maximum possible sum is 724269 real0m0.582s user0m0.191s sys 0m0.013s -- https://mail.python.org/mailman/listinfo/python-list
[issue23051] multiprocessing.pool methods imap() and imap_unordered() cause deadlock
Changes by Ned Deily n...@acm.org: -- nosy: +sbt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23051 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23052] python2.7.9 [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)
binbjz added the comment: I have added code to disable global verification on phsphere. It works well. thanks. -- resolution: not a bug - type: behavior - crash ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23052 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22706] Idle extension configuration and key bindings
Saimadhav Heblikar added the comment: Need some clarification on this issue. I tried changing the cfgBindings for FormatParagraph. It creates a new key-set and writes the changes to user config-keys.cfg in ~/.idlerc(the keybindings). Any changes made to FormatParagraph in extension dialog(the [X]) are written to the user config-extensions.cfg file in ~/.idlerc. Have I understood the issue correctly in saying that the desired outcome is both [X] and [X_cfgBindings] write to config-extensions.cfg in ~/.idlerc? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22706 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23015] Improve test_uuid
Roundup Robot added the comment: New changeset f972583c7c4f by Serhiy Storchaka in branch '2.7': Issue #23015: Improved testing of the uuid module. https://hg.python.org/cpython/rev/f972583c7c4f New changeset 3551dc8af54e by Serhiy Storchaka in branch '3.4': Issue #23015: Improved testing of the uuid module. https://hg.python.org/cpython/rev/3551dc8af54e New changeset fd1d994afe52 by Serhiy Storchaka in branch 'default': Issue #23015: Improved testing of the uuid module. https://hg.python.org/cpython/rev/fd1d994afe52 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23015 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22777] Test pickling with all protocols
Roundup Robot added the comment: New changeset 9927781e457f by Serhiy Storchaka in branch '2.7': Issue #22777: Test pickling with all protocols. https://hg.python.org/cpython/rev/9927781e457f New changeset 04c9fffde184 by Serhiy Storchaka in branch '3.4': Issue #22777: Test pickling with all protocols. https://hg.python.org/cpython/rev/04c9fffde184 New changeset 77fc30182dc2 by Serhiy Storchaka in branch 'default': Issue #22777: Test pickling with all protocols. https://hg.python.org/cpython/rev/77fc30182dc2 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22777 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23015] Improve test_uuid
Changes by Serhiy Storchaka storch...@gmail.com: -- assignee: - serhiy.storchaka resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23015 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22777] Test pickling with all protocols
Changes by Serhiy Storchaka storch...@gmail.com: -- assignee: - serhiy.storchaka resolution: - fixed stage: patch review - resolved ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22777 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22818] Deprecate splitting on possible zero-width re patterns
Serhiy Storchaka added the comment: I there are no objections I'm going to commit the patch soon. -- assignee: - serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22818 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22826] Support context management protocol in bkfile
Changes by Serhiy Storchaka storch...@gmail.com: -- keywords: +needs review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22826 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19858] Make pickletools.optimize aware of the MEMOIZE opcode.
Serhiy Storchaka added the comment: Ping. -- keywords: +needs review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19858 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18473] some objects pickled by Python 3.x are not unpicklable in Python 2.x because of incorrect REVERSE_IMPORT_MAPPING
Serhiy Storchaka added the comment: Ping. -- keywords: +needs review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18473 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22783] Pickle: use NEWOBJ instead of NEWOBJ_EX if possible
Serhiy Storchaka added the comment: Ping. -- keywords: +needs review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22783 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15513] Correct __sizeof__ support for pickle
Serhiy Storchaka added the comment: Ping. -- keywords: +needs review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15513 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21279] str.translate documentation incomplete
John Posner added the comment: Kindly ignore message #2 on the Rietveld page (sorry for the channel noise). Here's my suggested revision: Return a copy of the string *str* in which each character has been mapped through the given translation *table*. The table must be a subscriptable object, for instance a list or dictionary; when subscripted (indexed) by a Unicode ordinal (an integer in range(1048576)), the table object can: * return a Unicode ordinal or a string, to map the character to one or more other characters. * return None, to delete the character from the return string. * raise a LookupError (possibly an instance of subclass IndexError or KeyError), to map the character to itself. -- nosy: +jjposner ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21279 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23053] test_urllib2_localnet fails without ssl
New submission from jan matejek: The pep 476 commit to Python 2.7 [1] adds unconditional import ssl to test_urllib2_localnet.py. This causes the test to fail with an ImportError if ssl module is not built. Note that like 5 lines later, ssl is imported conditionally, and all the relevant tests are configured to skip if ssl is not present. So to fix this, all that is needed is to remove the import ssl line. Attached patch does just that. [1] https://hg.python.org/cpython/rev/fb83916c3ea1 -- components: Tests files: python-2.7-urllib2-localnet-ssl.patch keywords: patch messages: 232663 nosy: matejcik priority: normal severity: normal status: open title: test_urllib2_localnet fails without ssl type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file37454/python-2.7-urllib2-localnet-ssl.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23054] ConnectionError: ('Connection aborted.', BadStatusLine(''''))
New submission from Joe Cabrera:
ConnectionError: ('Connection aborted.', BadStatusLine())
This error can also occur on Linux and Windows, a more descriptive error
messages would be useful for people trying to debug their code.
--
assignee: docs@python
components: Documentation
messages: 232664
nosy: docs@python, joecabrera
priority: normal
severity: normal
status: open
title: ConnectionError: ('Connection aborted.', BadStatusLine())
type: behavior
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23054
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23053] test_urllib2_localnet fails without ssl
Roundup Robot added the comment: New changeset ebe8917189a3 by Benjamin Peterson in branch '2.7': remove extra ssl imports (closes #23053) https://hg.python.org/cpython/rev/ebe8917189a3 New changeset 1da9e9eaeae8 by Benjamin Peterson in branch '3.4': remove extra ssl imports (closes #23053) https://hg.python.org/cpython/rev/1da9e9eaeae8 New changeset 8214675f6385 by Benjamin Peterson in branch 'default': merge 3.4 (#23053) https://hg.python.org/cpython/rev/8214675f6385 -- nosy: +python-dev resolution: - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23054] ConnectionError: ('Connection aborted.', BadStatusLine(''''))
R. David Murray added the comment: I think you made a mistake in your copy and paste or retyping of that line, since it is not valid python syntax. What is not explicit about it? It is telling you there was a bad status line, and what the bad status line contents was. (Used to be you couldn't tell, when the badness of the status line was that it was empty, that that was what the error message was saying, but I'm pretty sure we fixed that so that it shows an empty status line as an empty string in the message). -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23054 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23054] ConnectionError: ('Connection aborted.', BadStatusLine(''''))
R. David Murray added the comment: Perhaps part of your problem is that you are not getting the string representation of the error message. Is that because of your code, or is this representation something the stdlib is generating? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23054 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23050] Add Japanese legacy encodings
STINNER Victor added the comment: These character encodings are legacy, but are still used. Do you have an idea of how many users still have documents stored or exchanged using these encodings? The patch is not trivial, the legacy japanese codecs are complex and so error prone :-/ For previous requests to add new codecs, we closed issues as wontfix and we suggested to share the codecs at the Python Cheeseshop (PyPI). Here it's more complex because C code is modified to implement the new encodings. $ diffstat issue23050_13417.diff Doc/library/codecs.rst | 16 Lib/encodings/aliases.py | 26 Lib/test/test_codecencodings_iso2022.py | 59 + Lib/test/test_codecs.py |2 Lib/test/test_multibytecodec.py |6 Lib/test/test_xml_etree.py |4 Modules/cjkcodecs/_codecs_iso2022.c | 718 ++- Modules/cjkcodecs/_codecs_jp.c | 305 + Modules/cjkcodecs/mappings_jp.h | 950 ++- Modules/cjkcodecs/multibytecodec.h | 11 Python/importlib.h | 860 ++-- b/Lib/encodings/cp50220.py | 39 + b/Lib/encodings/cp50221.py | 39 + b/Lib/encodings/cp50222.py | 39 + b/Lib/encodings/cp51932.py | 39 + b/Lib/encodings/eucjp_ms.py | 39 + b/Lib/encodings/iso2022_jp_ms.py | 39 + b/Lib/test/cjkencodings/cp50220-utf8.txt | 30 b/Lib/test/cjkencodings/cp50220.txt | 30 b/Modules/cjkcodecs/mappings_cp50220_k.h | 31 + 20 files changed, 2452 insertions(+), 830 deletions(-) -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23050 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22875] asyncio: call_soon() documentation unclear on timing
STINNER Victor added the comment: Thanks Martin for your change, I commited it. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22875 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22875] asyncio: call_soon() documentation unclear on timing
STINNER Victor added the comment: Oops, I forgot to mention the issue number in my commit. changeset: 93893:a59fed8c710b branch: 3.4 parent: 93891:1da9e9eaeae8 user:Victor Stinner victor.stin...@gmail.com date:Mon Dec 15 17:50:55 2014 +0100 files: Doc/library/asyncio-eventloop.rst description: asyncio doc: call_soon() does not call immediatly the callback. Patch written by Martin Panter. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22875 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14134] xmlrpc.client.ServerProxy needs timeout parameter
Demian Brecht added the comment:
+ loewis as he's listed as the xmlrpc expert
If you're worried about the number of lines, turn the function into a lambda:
proxy = ServerProxy('http://example.com/gateway/', transport=Transport(
connection_factory=lambda h: HTTPConnection(h, timeout=42)))
I think that the problem with the way that you're looking at the problem:'just
only for adding timeout', when what you're fundamentally after is to modify
the attribute of an object two levels removed by composition.
I /do/ agree that this is slightly more complex than simply setting a timeout
parameter, but I also think that it's actually quite a bit more flexible and
practically useful.
Borrowing from PEP20: There should be one-- and preferably only one --obvious
way to do it.. Having a timeout at the top level ServerProxy object introduces
ambiguity and therefore doesn't conform. Should the connection_factory concept
be used, having a timeout parameter at the Transport level also introduces
ambiguity. Setting the timeout through a custom HTTPConnection instantiated
through connection_factory is an obvious way to do it (especially if
documented) and is marginally more code.
If you /only/ care about the timeout and really don't want to be bothered with
the connection_factory, you can always set the global socket timeout for the
given request with:
socket.setdefaulttimeout([timeout])
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14134
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22875] asyncio: call_soon() documentation unclear on timing
STINNER Victor added the comment: FYI I added a new test to the aiotest project (test suite for asyncio), for this issue: https://bitbucket.org/haypo/aiotest/commits/17dd11fc2f4bafad623f940b1a33a3b8b0d39ccd -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22875 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23055] PyUnicode_FromFormatV crasher
New submission from Guido van Rossum: Fix as reported by Guido Vranken on secur...@python.org, with minimal test by me. Needs: - review - port to 3.2--3.5 Questions: - Does my test case cover all changed code? -- assignee: gvanrossum files: vranken.diff keywords: needs review, patch messages: 232673 nosy: gvanrossum priority: normal severity: normal status: open title: PyUnicode_FromFormatV crasher type: crash versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37455/vranken.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23055 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23050] Add Japanese legacy encodings
Tetsuya Morimoto added the comment: These character encodings are legacy, but are still used. Do you have an idea of how many users still have documents stored or exchanged using these encodings? Hmm, I guess iso-2022-jp codec is still default charset of MUA (Mail User Agent) on Japanese Windows platform. But I'm not sure how many so I'll investigate, wait a few days. The patch is not trivial, the legacy japanese codecs are complex and so error prone :-/ Ya, this patch has some refactoring. However, existing tests have passed and adding encoding codecs wouldn't affect other codecs basically. Why do you think it's error plone? For previous requests to add new codecs, we closed issues as wontfix and we suggested to share the codecs at the Python Cheeseshop (PyPI). Here it's more complex because C code is modified to implement the new encodings. Could you show me previous requests? I can understand C code modifying is higher cost to review. However, we have codec tests and it wouldn't affect other codecs, I think. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23050 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23056] tarfile raises an exception when reading an empty tar in streaming mode
New submission from Gregory P. Smith: $ cat test.py EOF import tarfile import sys with tarfile.open(sys.argv[1], mode=r|*) as f: while True: info = f.next() if not info: break EOF $ tar cf test.tar -T /dev/null $ python2.7 test.py test.tar Traceback (most recent call last): File test.py, line 6, in module info = f.next() File /usr/lib/python2.7/tarfile.py, line 2319, in next self.fileobj.seek(self.offset) File /usr/lib/python2.7/tarfile.py, line 555, in seek raise StreamError(seeking backwards is not allowed) tarfile.StreamError: seeking backwards is not allowed $ python3.4 test.py test.tar Traceback (most recent call last): File test.py, line 6, in module info = f.next() File /usr/lib/python3.4/tarfile.py, line 2244, in next self.fileobj.seek(self.offset) File /usr/lib/python3.4/tarfile.py, line 518, in seek raise StreamError(seeking backwards is not allowed) tarfile.StreamError: seeking backwards is not allowed I have reconfirmed that the above still happens using a top of tree 2.7.9+ build. -- components: Library (Lib) messages: 232675 nosy: gregory.p.smith priority: normal severity: normal stage: needs patch status: open title: tarfile raises an exception when reading an empty tar in streaming mode type: behavior versions: Python 2.7, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23056 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23041] csv needs more quoting rules
Samwyse added the comment: Yes, it's based on a real-world need. I work for a Fortune 500 company and we have an internal tool that exports CSV files using what I've described as the QUOTE_NOTNULL rules. I need to create similar files for re-importation. Right now, I have to post-process the output of my Python program to get it right. I added in the QUOTE_STRINGS rule for completeness. I think these two new rules would be useful for anyone wanting to create sparse CSV files. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23041 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23041] csv needs more quoting rules
Skip Montanaro added the comment: If I understand correctly, your software needs to distinguish between # wrote [foo, , 42, None] with quote_all in effect foo,,42, and # wrote [foo, None, 42, ] with quote_nonnull in effect foo,,42, so you in effect want to transmit some type information through a CSV file? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23041 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23057] asyncio loop on Windows should stop on keyboard interrupt
New submission from Andrew Svetlov: See http://stackoverflow.com/questions/27480967/why-does-the-asyncios-event-loop-suppress-the-keyboardinterrupt-on-windows for details -- components: asyncio messages: 232678 nosy: asvetlov, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio loop on Windows should stop on keyboard interrupt type: behavior versions: Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23057 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23058] argparse silently ignores arguments
New submission from Rémi Rampin:
This works correctly on Python 3.4.
On Python 2.7, argparse seems to completely and silently ignore arguments in
some conditions, for instance this setup will cause --verbose to be ignored on
the main parser:
options = argparse.ArgumentParser(add_help=False)
options.add_argument('-v', '--verbose', action='store_true')
parser = argparse.ArgumentParser(parents=[options])
subparsers = parser.add_subparsers()
parser_cmd = subparsers.add_parser('cmd', parents=[options])
Full runnable example here:
http://paste.pound-python.org/show/XfVVhdJHSPISXLP1lASd/
Might or might not be related to #9351, workarounds welcome.
--
components: Library (Lib)
messages: 232679
nosy: remram
priority: normal
severity: normal
status: open
title: argparse silently ignores arguments
type: behavior
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23058
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23059] sort misc help topics in cmd
New submission from Samwyse: I've discovered that do_help method of cmd.Cmd prints the documented and undocumented commands in sorted order, but does not sort the miscellaneous topics. This would be an easy fix, just change self.print_topics(self.misc_header, help.keys(),15,80) to use sorted(help.keys()). -- components: Library (Lib) messages: 232680 nosy: samwyse priority: normal severity: normal status: open title: sort misc help topics in cmd versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23059 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23041] csv needs more quoting rules
Samwyse added the comment: Skip, I don't have any visibility into how the Java program I'm feeding data into works, I'm just trying to replicate the csv files that it exports as accurately as possible. It has several other quirks, but I can replicate all of them using Dialects; this is the only feature I can't. The files I'm looking at have quoted strings and numbers, but there aren't any quoted empty strings. I'm using a DictWriter to create similar csv files, where missing keys are treated as values of None, so I'd like those printed without quotes. If we also want to print empty strings without quotes, that wouldn't impact me at all. Besides my selfish needs, this could be useful to anyone wanting to reduce the save of csv files that have lots of empty fields, but wants to quote all non-empty values. This may be an empty set, I don't know. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23041 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23058] argparse silently ignores arguments
Rémi Rampin added the comment: Interestingly, this worked before my upgrade 2.7.8 - 2.7.9. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23058 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22826] Support context management protocol in bkfile
Berker Peksag added the comment: The second patch raises RuntimeError: maximum recursion depth exceeded if the target file is exist. File /home/berker/projects/cpython/default/Tools/freeze/bkfile.py, line 18, in close f.close() RuntimeError: maximum recursion depth exceeded -- nosy: +berker.peksag ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22826 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23050] Add Japanese legacy encodings
STINNER Victor added the comment: I refactored some parts of CJK codecs for performances, after the PEP 393 was implemented. A blocker point was that these codecs have very few tests. Not for valid data but for invalid data. It may be a little bit better. I tried to write a test for each path in if/else, to test all cases, in the codecs that I modified. By error prone, it mean that it's easy to introduce a bug or a regressio, since the code is complex and almost nobody maintains it. I'm not stongly opposed to any change. I'm just trying to understand the context. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23050 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23050] Add Japanese legacy encodings
Martin v. Löwis added the comment: Another traditional issue with Japanese codecs is that people have different opinions on what the encoding should do. It may be that when we release the codec, somebody comes up and says that the codec is incorrect, and it should do something different for some code points, citing some other applications which he considers right. In particular for the Microsoft ones, people may claim that some version of Windows did things differently. Now, for this set, the ones that got registered with IANA sound ok (in the sense that it is our bug if they fail to conform to the IANA spec, and IANA's fault if they fail to do what users expect). For the other ones, I wonder whether there is some official source that can be consulted for correctness. On a different note: why do you claim that the code is written by Perky? (it's not you, is it?) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23050 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22783] Pickle: use NEWOBJ instead of NEWOBJ_EX if possible
Serhiy Storchaka added the comment: Some examples (with issue19858 for protocol 4 optimization). Unpatched: len(pickle.dumps([P(12, 34) for i in range(1000)], 3)) 17258 len(pickletools.optimize(pickle.dumps([P(12, 34) for i in range(1000)], 3))) 8018 len(pickle.dumps([P(i, -i) for i in range(1000)], 3)) 20999 len(pickletools.optimize(pickle.dumps([P(i, -i) for i in range(1000)], 3))) 11759 len(pickle.dumps([P(12, 34) for i in range(1000)], 4)) 12031 len(pickletools.optimize(pickle.dumps([P(12, 34) for i in range(1000)], 4))) 9028 len(pickle.dumps([P(i, -i) for i in range(1000)], 4)) 15772 len(pickletools.optimize(pickle.dumps([P(i, -i) for i in range(1000)], 4))) 12769 Patched: len(pickle.dumps([P(12, 34) for i in range(1000)], 4)) 10031 len(pickletools.optimize(pickle.dumps([P(12, 34) for i in range(1000)], 4))) 8028 len(pickle.dumps([P(i, -i) for i in range(1000)], 4)) 13772 len(pickletools.optimize(pickle.dumps([P(i, -i) for i in range(1000)], 4))) 11769 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22783 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22826] Support context management protocol in bkfile
Serhiy Storchaka added the comment: Good catch Berker. Updated patch fixes recursion issue. -- Added file: http://bugs.python.org/file37456/bkfile3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22826 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21740] doctest doesn't allow duck-typing callables
Roundup Robot added the comment: New changeset 12ef799a9a51 by Zachary Ware in branch 'default': Issue #21740: Fix module name in NEWS entry. https://hg.python.org/cpython/rev/12ef799a9a51 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21740 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23055] PyUnicode_FromFormatV crasher
Serhiy Storchaka added the comment: I have added a couple of comments. Here is a patch which fixes found bugs. 3.4+ is not affected by this bug. 3.2 looks same as 2.7 and is affected, 3.3 uses different code but at first glance looks affected too. Is it worth to fix this bug in 3.2 and 3.3? -- components: +Interpreter Core nosy: +georg.brandl, haypo, serhiy.storchaka stage: - patch review versions: -Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37457/issue23055-2.7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23055 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23055] PyUnicode_FromFormatV crasher
Guido van Rossum added the comment: Thank you for digging into this! I'd say go ahead and update 3.2 and 3.3 too -- these are in security-fix-only mode meaning that we only fix security issues and don't do actual releases. But we still do security bugfixes: for 3.2 until February 2016 (PEP 392), for 3.3 until September 2017 (PEP 398). I don't think that this warrants changing the 2.7 bugfix release schedule. -- versions: +Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23055 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23055] PyUnicode_FromFormatV crasher
Guido Vranken added the comment: Serhiy Storchaka: good call on changing my 'n += (width + precision) 20 ? 20 : (width + precision);' into 'if (width precision) width = precision;', I didn't realize that sprintf's space requirement entails using the largest of the two instead of adding the two together. I noticed the apparently pointless width calculation in 'step 1' but decided not to touch it -- good that it's removed now though. I will start doing more debugging based on this new patch now to ensure that the bug is gone now. On a more design-related note, for the sake of readability and stability, I'd personally opt for implementing toned-down custom sprintf-like function that does exactly what it needs to do and nothing more, since a function like this one requires perfect alignment with the underlying sprintf() in terms of functionality, at the possible expense of stability and integrity issues like we see here. For instance, width and precision are currently overflowable, resulting in either a minus sign appearing in the resulant format string given to sprintf() (width and precision are signed integers), or completely overflowing it (ie. (uint64_t)18446744073709551617 == 1 ). Considering the latter example, how do we know sprintf uses the same logic? Guido -- nosy: +Guido ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23055 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23055] PyUnicode_FromFormatV crasher
Guido Vranken added the comment: I'd also like to add that, although I agree with Guido van Rossum that the likelihood of even triggering this bug in a general programming context is low, there are two buffer overflows at play here (one stack-based and one heap-based), and given an adversary's control over the format and vargs parameters, I'd there is a reasonable likelihood of exploiting it to execute arbitrary code, since the one controlling the parameters has some control as to which bytes end up where outside buffer boundaries. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23055 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23004] mock_open() should allow reading binary data
Aaron Hill added the comment: I've fixed the issues you pointed out. Is there a better way than uploading a new patch file to make changes? -- Added file: http://bugs.python.org/file37458/mock-open-allow-binary-without-coerce-fixup.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23004 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23055] PyUnicode_FromFormatV crasher
Guido van Rossum added the comment: I'd be much worried about attack scenarios if this function was part of the standard library. But it's not -- the stdlib's % operator uses completely different code. The most common use case is probably to generate error messages from extension modules -- and there the format is almost always a literal in the C code. (An adversary who can load a C extension doesn't need this exploit.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23055 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21279] str.translate documentation incomplete
Martin Panter added the comment: I’m largely happy with any of these revisions. If I end up doing another patch I would omit the *str* (it is a class name, not a parameter). Also I would omit the range(2^20) claim. Unless people think it is important; why is it different to sys.maxunicode + 1 = 0x11? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21279 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22928] HTTP header injection in urrlib2/urllib/httplib/http.client
Martin Panter added the comment: There could be potential for breaking compatibility if people are intentionally sending values with folded lines (obsoleted by the new HTTP RFC). Perhaps the same error should be raised for values that cannot be encoded in Latin-1? Also, maybe most control characters should trigger an error, not just CR and LF. Apart from line folding, the HTTP RFC only allows visible ASCII characters, spaces and tabs, and obsolete non-ASCII chars = 0x80. -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22928 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23060] Assert fails in multiprocessing.heap.Arena.__setstate__ on Windows
New submission from Steve Dower: Currently, the implementation of __setstate__ at Lib/multiprocessing/heap.py:54 looks like this: def __setstate__(self, state): self.size, self.name = self._state = state self.buffer = mmap.mmap(-1, self.size, tagname=self.name) assert _winapi.GetLastError() == _winapi.ERROR_ALREADY_EXISTS This assertion can fail when the assignment to buffer triggers memory [re]allocation, which could clear the last error result. So far, this fails reliably on debug builds using VS 2015 (which causes some tests to timeout when all of the child processes fail to start), but could also fail in threaded code at any time. I don't know why release builds or builds with VS 2010 did not trigger this, but I would speculate that either VS 2015 is using a different API to allocate memory or Windows 8.1 has changed the behaviour of an API. Whether a function resets the last error code is deliberately unspecified (http://msdn.microsoft.com/en-us/library/windows/desktop/ms679360(v=vs.85).aspx - some functions set the last-error code to 0 on success and others do not). In my opinion, the assertion should just be removed. A hack that appears to work currently is to add self.buffer = None before the existing assignment (to pre-expand self.__dict__ and avoid the allocation). If the assertion is important, someone may want to add a parameter to mmap() to require that the memory-mapped file already exists and throws otherwise, but I am not volunteering to do this. -- components: Windows messages: 232697 nosy: jnoller, sbt, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Assert fails in multiprocessing.heap.Arena.__setstate__ on Windows versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23060 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23060] Assert fails in multiprocessing.heap.Arena.__setstate__ on Windows
Steve Dower added the comment: A buildbot failure due to this can be seen here: http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x/builds/183/steps/test/logs/stdio -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23060 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23059] cmd module should sort misc help topics
Changes by Samwyse samw...@gmail.com: -- title: sort misc help topics in cmd - cmd module should sort misc help topics ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23059 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23014] Don't have importlib.abc.Loader.create_module() be optional
Eric Snow added the comment: Thanks for bringing this up, Brett. The goal and approach seem good to me. Did you bring this up during the PEP 451 discussions? If so, sorry I missed it. You've made a good point. And hopefully this will encourage people to subclass Loader more. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23014 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23014] Don't have importlib.abc.Loader.create_module() be optional
Eric Snow added the comment: At some point should we make create_module (and exec_module) always required? In other words, when should would drop the legacy loader support? I expect the answer is Python 4. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23014 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19698] Implement _imp.exec_builtin and exec_dynamic
Eric Snow added the comment: Same here. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19698 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23050] Add Japanese legacy encodings
Tetsuya Morimoto added the comment: By error prone, it mean that it's easy to introduce a bug or a regression, since the code is complex and almost nobody maintains it. Indeed. Actually, I encountered some faults when I migrated original patch. The character encoding is a kind of specialty area. This patch is written by Masayuki Moriyama, who is an expert of character encoding and he have been contributed to various communities for a long time. Also, he helps me to migrate original patch(for Python 2.4.3) to Python 3.5. You can see commit log he fixed some bugs. https://bitbucket.org/t2y/cpython/commits/all I'm not stongly opposed to any change. I'm just trying to understand the context. Thanks. I'll help it by explaining the context. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23050 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21720] TypeError: Item in ``from list'' not a string message
Ben Finney added the comment: Is there room for a better resolution: fix the API so that Unicode objects are accepted in the ‘fromlist’ items? -- nosy: +bignose ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21720 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21720] TypeError: Item in ``from list'' not a string message
Changes by Ben Finney ben+pyt...@benfinney.id.au: ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21720 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23004] mock_open() should allow reading binary data
Demian Brecht added the comment: Thanks for the updated patch, looks good to me. If you haven't already read it, the patch workflow is here: https://docs.python.org/devguide/patch.html and is the only workflow currently available. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23004 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23004] mock_open() should allow reading binary data
Changes by Berker Peksag berker.pek...@gmail.com: -- stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23004 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14134] xmlrpc.client.ServerProxy needs timeout parameter
Andrej A Antonov added the comment:
@demian.brecht , socket.setdefaulttimeout([timeout]) -- it is bad practice,
because setting this global varible we may spoil other cases. example TCP
keepalive [ s.setsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE, true) ]
and global variables is bad practice for other things.
and again -- compare what shorter (and what more clear):
proxy = ServerProxy('http://example.com/gateway/', transport=Transport(
connection_factory=lambda h: HTTPConnection(h, timeout=42)))
or
proxy = ServerProxy('http://example.com/gateway/', timeout=42)
There should be one-- and preferably only one --obvious way to do it..
Having a timeout at the top level ServerProxy object introduces ambiguity and
therefore doesn't conform
if you NOT point timeout in RPC-client -- you program will freeze or will
maked resource leak (with small probability).
RPC-client and timeout -- these two concepts are inseparable!
you are allowed *NOT_using* timeout in RPC-client -- *ONLY* in *localhost*
operations!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14134
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23050] Add Japanese legacy encodings
Tetsuya Morimoto added the comment: Another traditional issue with Japanese codecs is that people have different opinions on what the encoding should do. It may be that when we release the codec, somebody comes up and says that the codec is incorrect, and it should do something different for some code points, citing some other applications which he considers right. In particular for the Microsoft ones, people may claim that some version of Windows did things differently. In regard to e-mail encoding, Japanese should use utf-8, then it resolves most problems. However, for historical reason or compatibility reason, it's different even today. I don't think these legacy codecs are needed for individual application, but we sometimes encounter an encoding issue when an application collaborates to external system like e-mail. Now, for this set, the ones that got registered with IANA sound ok (in the sense that it is our bug if they fail to conform to the IANA spec, and IANA's fault if they fail to do what users expect). For the other ones, I wonder whether there is some official source that can be consulted for correctness. Exactly. Now, I'm finding euc-jp-ms and iso-2022-jp-ms spec in English. Of course, there's a voluntary document in Japanese as follows. http://www.wdic.org/w/WDIC/eucJP-ms http://www.wdic.org/w/WDIC/ISO-2022-JP-MS I may agree with dropping character encoding which is difficult to find official source. On a different note: why do you claim that the code is written by Perky? (it's not you, is it?) Right! Because the credit belongs to him. I'm an assistant. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23050 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22733] MSVC ffi_prep_args doesn't handle 64-bit arguments properly
Steve Dower added the comment:
This patch also resolves this test issue:
[ 68/390/2] test_ttk_textonly
test test_ttk_textonly crashed -- Traceback (most recent call last):
File D:\...\lib\test\regrtest.py, line 1280, in runtest_inner
test_runner()
File D:\...\lib\test\test_ttk_textonly.py, line 14, in test_main
*runtktests.get_tests(gui=False, packages=['test_ttk']))
File D:\...\lib\tkinter\test\runtktests.py, line 65, in get_tests
for module in get_tests_modules(gui=gui, packages=packages):
File D:\...\lib\tkinter\test\runtktests.py, line 50, in get_tests_modules
tkinter.test)
File D:\...\lib\importlib\__init__.py, line 109, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File frozen importlib._bootstrap, line 2208, in _gcd_import
File frozen importlib._bootstrap, line 2191, in _find_and_load
File frozen importlib._bootstrap, line 2180, in _find_and_load_unlocked
File frozen importlib._bootstrap, line 1149, in _load_unlocked
File frozen importlib._bootstrap, line 1420, in exec_module
File frozen importlib._bootstrap, line 321, in _call_with_frames_removed
File D:\...\lib\tkinter\test\test_ttk\test_extensions.py, line 8, in
module
requires('gui')
File D:\...\lib\test\support\__init__.py, line 492, in requires
if resource == 'gui' and not _is_gui_available():
File D:\...\lib\test\support\__init__.py, line 436, in _is_gui_available
raise ctypes.WinError()
OSError: [WinError 0] The operation completed successfully.
I'm not entirely sure when/if I should just commit the fix without any reviews,
but this issue needs to be fixed, so eventually I'll probably just do it :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22733
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23061] Update pep8 to specify explicitly 'module level' imports at top of file
New submission from Ian Lee: Minor update pep8 to specify explicitly that Imports at top of file refers specifically to module level imports, per input from Nick Coghlan @ https://github.com/jcrocholl/pep8/pull/304#issuecomment-66939162 -- assignee: docs@python components: Documentation files: pep-0008.patch keywords: patch messages: 232708 nosy: IanLee1521, docs@python, ncoghlan priority: normal severity: normal status: open title: Update pep8 to specify explicitly 'module level' imports at top of file type: enhancement Added file: http://bugs.python.org/file37459/pep-0008.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23061 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14134] xmlrpc.client.ServerProxy needs timeout parameter
Andrej A Antonov added the comment: ok, let's go to other side of this problem: question: why default transport (xmlrpc.client.Transport()) is not setting value of timeout?`` answer: because *unknown* which value need to using by default. in various cases programmer need various timeout. default value of timeout for default transport -- what may be this number? may be value 300 for timeout of default transport (xmlrpc.client.Transport()) may be normal in *most_cases*. but this will brake legacy soft that using socket.setdefaulttimeout(...) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14134 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Roundup Robot added the comment: New changeset f70c16189876 by Steve Dower in branch 'default': #22980 Adds platform and version tags to .pyd files https://hg.python.org/cpython/rev/f70c16189876 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Steve Dower added the comment: Nobody seemed too bothered by it, so I committed a slightly simpler change that only includes the most specific tag (that is, .cp35-win32.pyd or .pyd). We can always add another tag easily enough if it seems useful, or roll this change back if it was a mistake. Now, let's stop talking about Windows and get back to the original discussion :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23062] test_argparse --version test cases
New submission from Martin Panter: In Lib/test/test_argparse.py: class TestHelpVersionOptional(HelpTestCase): Test that the --version argument can be suppressed help messages Assuming that the docstring means something like “. . . can be suppressed _in_ help messages”, the test is wrong, because the --version option is present in the expected output. Maybe it is missing a help=SUPPRESS option? Otherwise it seems this test class would be largely redundant with TestHelpVersionAction. It also looks like the “version” attribute of the test classes is not used. -- components: Tests messages: 232712 nosy: vadmium priority: normal severity: normal status: open title: test_argparse --version test cases versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23062 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22733] MSVC ffi_prep_args doesn't handle 64-bit arguments properly
Zachary Ware added the comment: I don't know near enough to comment on this one. If you feel confident in it, I'd say go ahead. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22733 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23062] test_argparse --version test cases
Berker Peksag added the comment: I think that your analysis is correct. Also, looks like the original test is problematic: https://code.google.com/p/argparse/source/browse/test/test_argparse.py#3710 Here is a patch to fix the test. -- keywords: +patch nosy: +berker.peksag, bethard, paul.j3 stage: - patch review type: - behavior versions: +Python 3.4 Added file: http://bugs.python.org/file37460/issue23062.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23062 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9694] argparse required arguments displayed under optional arguments
Martin Panter added the comment: Here is much larger patch in the spirit of Ryan’s, that fixes the documentation, adjusts the tests, and some of the internal comments and variable names in the source code as well. However if some changes are too controversial, I am happy to simplify it to (say) Ryan’s patch plus the minimum test fixes. -- versions: +Python 3.5 Added file: http://bugs.python.org/file37461/option-internal.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9694 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22945] Ctypes inconsistent between Linux and OS X
Ned Deily added the comment: Thanks, eryksun. Any objections to closing this issue? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22945 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22912] urlretreive locks up in 2.7.8
Changes by Ned Deily n...@acm.org: -- nosy: +orsenthil -ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22912 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22672] float arguments in scientific notation not supported by argparse
Changes by Ned Deily n...@acm.org: -- nosy: -ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22672 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22706] Idle extension configuration and key bindings
Terry J. Reedy added the comment: When I alter an *extension* key binding (in the keys page of idle pref dialog), the change shows up in .idlerc/config-extensions.cfg, not config-keys.cfg. For instance, [ZoomHeight_cfgBindings] zoom-height = Control-Alt-Key-space If I also disable zoom-height, the following appears in a separate part of the same file. [XoomHeight] enable=False For me, the two blocks are already in the same file. The same is true for FormatParagraph. I intended this issue to be about bringing them together in the file, with the [X] block first. You seem to be saying that the current behavior is different on linux. Since FormatParagraph is still special (see #20577), try ZoomHeight also. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22706 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
