[issue26547] Undocumented use of the term dictproxy in vars() documentation

Martin Panter added the comment: In Python 2, the class was called “dictproxy”, the repr() used “dict_proxy” with an underscore, and it is exposed as types.DictProxyType. So I guess that is where the term comes from. In Python 3.3, Issue 14386 renamed the class and repr() to “mappingproxy”,

[issue23214] BufferedReader.read1(size) signature incompatible with BufferedIOBase.read1(size=-1)

Serhiy Storchaka added the comment: Shouldn't read1(-1) be the same as read1(sys.maxsize)? I.e. read from a buffer without limit. -- nosy: +benjamin.peterson, pitrou, serhiy.storchaka, stutzbach ___ Python tracker

[issue25687] Error during test case and tearDown

Roundup Robot added the comment: New changeset cecd39887faa by Ezio Melotti in branch '3.5': #25687: clarify that errors in tearDown increase the total number of reported errors. Initial patch by HyeSoo Park. https://hg.python.org/cpython/rev/cecd39887faa New changeset d5f5a6f514f2 by Ezio

[issue25687] Error during test case and tearDown

Ezio Melotti added the comment: Fixed, thanks for the report and the patch! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue26495] super() does not work in nested functions, genexps, listcomps, and gives misleading exceptions

Changes by Raymond Hettinger : -- Removed message: http://bugs.python.org/msg261264 ___ Python tracker ___

[issue26525] Documentation of ord(c) easy to misread

Raymond Hettinger added the comment: I concur that the Euro sign would be best (more recognizable and more likely to be renderable in a given font). -- nosy: +rhettinger ___ Python tracker

[issue26535] Minor typo in the docs for struct.unpack

Changes by Serhiy Storchaka : -- stage: patch review -> needs patch ___ Python tracker ___

[issue26545] os.walk is limited by python's recursion limit

Raymond Hettinger added the comment: I think the code should be left as-is (we've used some variation of recursion for walking a very long time with no reported real-world problems). Perhaps a documentation note can be added to the effect that the there is a recursion limit and that it can

[issue26535] Minor typo in the docs for struct.unpack

Changes by Serhiy Storchaka : -- nosy: +pitrou ___ Python tracker ___ ___

[issue26314] interned strings are stored in a dict, a set would use less memory

Serhiy Storchaka added the comment: Since interned strings table can only grow and contains exact strings, other data structure may be more appropriate (for example Modules/hashtable.c). But for now status quo is good to me. -- ___ Python tracker

Re: Descriptors vs Property

Thomas 'PointedEars' Lahn wrote: >> I haven't read the descriptor protocol as yet. > > You should. You should also trim your quotations to the relevant > minimum, and post using your real name. > I don't take advice from people on USENET who DON'T have a long history of helping ME - unless

[issue26511] Add link to id() built-in in comparison operator documentation for "is"

Changes by Ezio Melotti : -- keywords: +easy nosy: +ezio.melotti ___ Python tracker ___

[issue26535] Minor typo in the docs for struct.unpack

Raymond Hettinger added the comment: The proposed wording looks fine. -- nosy: +rhettinger ___ Python tracker ___

[issue26511] Add link to id() built-in in comparison operator documentation for "is"

Raymond Hettinger added the comment: I agree with the OP that is would be useful to link to id(). I also concur with Terry that integer caching is to remain an undocumented implementation specific detail (just an optimization). Also, Martin is correct that the proposed wording doesn't read

[issue26512] Vocabulary: Using "integral" in library/stdtypes.html

Raymond Hettinger added the comment: I don't think taking the table out makes the docs better. It just removes a source of information just because the OP stumbled on the word "integral" which has both a standard (albeit erudite) meaning in Engligh and a precise meaning in the context of

[issue26314] interned strings are stored in a dict, a set would use less memory

Gregory P. Smith added the comment: The space for the strings is a fixed cost, the structure used to store them for efficient lookup is the only overhead that can be trimmed and is all in one contiguous allocation. regardless, i agree, this isn't a large savings. priority low, feel free to

[issue26548] Probably missing word in a sentence in the doc of bitwise operations on integer types

Changes by Raymond Hettinger : -- resolution: -> fixed status: open -> closed ___ Python tracker ___

[issue26548] Probably missing word in a sentence in the doc of bitwise operations on integer types

Roundup Robot added the comment: New changeset b9256d5f1ab4 by Raymond Hettinger in branch '3.5': Issue #26548: Minor fix to awkward wording in docs https://hg.python.org/cpython/rev/b9256d5f1ab4 -- nosy: +python-dev ___ Python tracker

[issue26548] Probably missing word in a sentence in the doc of bitwise operations on integer types

Changes by Raymond Hettinger : -- assignee: docs@python -> rhettinger nosy: +rhettinger priority: normal -> low ___ Python tracker

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

On 3/12/2016 8:20 PM, Steven D'Aprano wrote: Yeah, we get it. The CPython interpreter is plenty fast enough for whatever you use it for. Good for you! Millions aren't so lucky. They are looking for something faster, because for them, you can never have too much speed. When you are trying to

[issue26314] interned strings are stored in a dict, a set would use less memory

Raymond Hettinger added the comment: I agree with Serhiy that this should not be done. IIRC, there were some discussions on python-dev or python-ideas about using sets for interning and the judgment was the dicts are conceptually the right type and that using sets would be hack. The other

[issue26499] http.client.IncompleteRead from HTTPResponse read after part reading file

Martin Panter added the comment: Thanks Silent Ghost, this patch looks pretty good. I did leave a couple more comments. Also I just realized that HTTPResponse.readline() and read1() are not really documented. The BufferedIOBase support was meant to be added in 3.5, although readline() was

[issue23214] BufferedReader.read1(size) signature incompatible with BufferedIOBase.read1(size=-1)

Martin Panter added the comment: Looking at this again, I think a less intrusive way forward would be to: * Document that in 3.6, the required signature is now BufferedIOBase.read1(size). An implementation no longer has to provide a default size, and no longer has to accept negative sizes. *

[issue26550] documentation minor issue : "Step back: WSGI" section from "HOWTO Use Python in the web"

New submission from Alejandro Soini: Bad article usage in the following sentence from the WSGI section on HOWTO Use Python in the web (https://docs.python.org/2/howto/webservers.html#wsgi) : "Authentication is another a problem easily solved using existing middleware." suggested change:

[issue26547] Undocumented use of the term dictproxy in vars() documentation

Serhiy Storchaka added the comment: I would add a space between "dict" and "proxy". -- nosy: +martin.panter, serhiy.storchaka ___ Python tracker ___

Re: Encapsulation in Python

On Sun, Mar 13, 2016 at 2:36 PM, Rick Johnson wrote: > On Saturday, March 12, 2016 at 3:10:49 PM UTC-6, Chris Angelico wrote: >> Also, if currentModule.py is pulling foo from modX, then modZ.py is an >> implementation detail. You don't necessarily want to go straight

Re: Psycopg2 to create a record using a FK

On Sat, Mar 12, 2016 at 9:57 PM, Aaron Christensen < aaron.christen...@gmail.com> wrote: > > > On Sat, Mar 12, 2016 at 5:03 AM, dieter wrote: > >> Aaron Christensen writes: >> > I am running the following versions of software: >> > >> > Python

Re: Encapsulation in Python

On Saturday, March 12, 2016 at 3:10:49 PM UTC-6, Chris Angelico wrote: > Also, if currentModule.py is pulling foo from modX, then modZ.py is an > implementation detail. You don't necessarily want to go straight > there; tracing the chain is more likely to be the correct behaviour. > Suppose

Re: Pyhon 2.x or 3.x, which is faster?

On Sun, 13 Mar 2016 02:36 am, alister wrote about building up strings by repeated concatenation: > So you are bench marking python performance on a programming paradigm > that is not good python practice. > > A pointless exercise > what may be the best way to achieve a rsult in one language is

Re: Encapsulation in Python

On Saturday, March 12, 2016 at 10:45:43 AM UTC-6, Ian wrote: > On Fri, Mar 11, 2016 at 7:39 PM, Rick Johnson > wrote: > > At run-time, i don't care how large a "module namespace" may > > be. Sometimes a module namespace will be small, with only a > > few exposed

Re: Psycopg2 to create a record using a FK

On Sat, Mar 12, 2016 at 5:03 AM, dieter wrote: > Aaron Christensen writes: > > I am running the following versions of software: > > > > Python 3.5 > > psycopg2==2.6.1 > > Postgres 9.4.5 > > > > I have 2 tables. Table User has UserId (serial

Re: Psycopg2 to create a record using a FK

On Sat, Mar 12, 2016 at 5:26 AM, Peter Otten <__pete...@web.de> wrote: > Aaron Christensen wrote: > > > Hello, > > > > I am running the following versions of software: > > > > Python 3.5 > > psycopg2==2.6.1 > > Postgres 9.4.5 > > > > I have 2 tables. Table User has UserId (serial PK), LastName,

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

On 13/03/2016 02:01, Steven D'Aprano wrote: On Sun, 13 Mar 2016 10:57 am, BartC wrote: I use 'const' everywhere in other languages, most often in the form of sophisticated sets of enums. A single project might have 1000 or even 2000. (Example that defines a set of byte-codes:

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

Mark Lawrence writes: > BartC would still be a complete idiot, as the complete crap that he's > been spewing over the last days puts him into the same league as the > RUE, possibly worse. It is so obvious that he knows nothing about > Python that I find it stunning that

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

On Sun, 13 Mar 2016 10:57 am, BartC wrote: > I use 'const' everywhere in other languages, most often in the form of > sophisticated sets of enums. A single project might have 1000 or even > 2000. (Example that defines a set of byte-codes: > http://pastebin.com/q1UwjKmK) > > How does Python

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

On Sun, Mar 13, 2016 at 12:32 PM, Mark Lawrence wrote: > > Python works and is extremely successful. If it were made even faster it > would be even more successful. BartC would still be a complete idiot, as > the complete crap that he's been spewing over the last days

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

On 13/03/2016 01:20, Steven D'Aprano wrote: On Sun, 13 Mar 2016 04:02 am, Mark Lawrence wrote: So I am clearly not the only programmer in the world who couldn't care less about speed. For somebody who couldn't care less, you sure do keep going on and on and on and on and on and on and on

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

On Sun, 13 Mar 2016 04:02 am, Mark Lawrence wrote: > So I am clearly not the only programmer in the world who couldn't care > less about speed. For somebody who couldn't care less, you sure do keep going on and on and on and on and on and on and on about it. Yeah, we get it. The CPython

[issue747320] rfc2822 formatdate functionality duplication

Berker Peksag added the comment: -now = time.time() -year, month, day, hh, mm, ss, x, y, z = time.localtime(now) -s = "%02d/%3s/%04d %02d:%02d:%02d" % ( -day, self.monthname[month], year, hh, mm, ss) +s = time.strftime("%d/%b/%Y %H:%M:%S",

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

On 12/03/2016 23:57, BartC wrote: On 12/03/2016 22:10, Marko Rauhamaa wrote: Chris Angelico : I completely agree with you that the keyword should mean "write-once" or "never rebind". That would be possible. I'm afraid that would result in people sprinkling these "constant"

[issue19450] Bug in sqlite in Windows binaries

Changes by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

On 12/03/2016 22:10, Marko Rauhamaa wrote: Chris Angelico : I completely agree with you that the keyword should mean "write-once" or "never rebind". That would be possible. I'm afraid that would result in people sprinkling these "constant" keywords everywhere to make the

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

Chris Angelico : > On Sun, Mar 13, 2016 at 9:10 AM, Marko Rauhamaa wrote: >> Chris Angelico : >> >>> I completely agree with you that the keyword should mean >>> "write-once" or "never rebind". >> >> That would be possible. I'm afraid that

[issue26549] co_stacksize is calculated from unoptimized code

New submission from Antti Haapala: When answering a question on StackOverflow, I noticed that a function that only loads a constant tuple to a local variable still has a large `co_stacksize` as if it was built with BUILD_TUPLE. e.g. >>> def foo(): ... a = (1,2,3,4,5,6,7,8,9,10)

[issue26548] Probably missing word in a sentence in the doc of bitwise operations on integer types

New submission from Julien: In https://docs.python.org/3.5/library/stdtypes.html#bitwise-operations-on-integer-types the sentence "this assumes a sufficiently large number of bits that no overflow occurs during the operation" looks wrong to me, so I asked on #python and got from @benzrf:

[issue23606] ctypes.util.find_library("c") no longer makes sense

Eryk Sun added the comment: I occasionally come across code snippets on Stack Overflow, and projects such as win-unicode-console (IIRC), that use ctypes to work with C stdio FILE streams (sometimes for dubious reasons, such as a DLL API that uses FILE streams). Maybe the _ctypes extension

[issue26547] Undocumented use of the term dictproxy in vars() documentation

New submission from Julien: I spotted un undocumented term here : https://docs.python.org/3.5/library/functions.html#vars in: "Objects such as modules and instances have an updateable __dict__ attribute; however, other objects may have write restrictions on their __dict__ attributes (for

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

On Sun, Mar 13, 2016 at 9:10 AM, Marko Rauhamaa wrote: > Chris Angelico : > >> I completely agree with you that the keyword should mean "write-once" >> or "never rebind". > > That would be possible. I'm afraid that would result in people > sprinkling these

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

On 12/03/2016 19:26, Thomas 'PointedEars' Lahn wrote: BartC wrote: On 12/03/2016 12:13, Marko Rauhamaa wrote: Why, look at the *English* page on Hillary Clinton: Hillary Diane Rodham Clinton /ˈhɪləri daɪˈæn ˈrɒdəm ˈklɪntən/ (born October 26, 1947) is an American politician.

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

Chris Angelico : > I completely agree with you that the keyword should mean "write-once" > or "never rebind". That would be possible. I'm afraid that would result in people sprinkling these "constant" keywords everywhere to make the program supposedly run faster. -- Something

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

On Sun, Mar 13, 2016 at 3:22 AM, Steven D'Aprano wrote: > On Sat, 12 Mar 2016 01:20 pm, Chris Angelico wrote: > > Definitely agree with this. Having a way to declare that a name is "truly constant" would be extremely handy; there currently isn't a way, and I'm

[issue26176] EmailMessage example doesn't work

Julien added the comment: Is this your bug: Traceback (most recent call last): File "/tmp/email_example.py", line 9, in with open(textfile) as fp: NameError: name 'textfile' is not defined ? If not, can you please provide us the full traceback ? -- nosy: +sizeof

[issue26483] docs unclear on difference between str.isdigit() and str.isdecimal()

Julien added the comment: To dig further, the DIGIT_MASK and DECIMAL_MASK used in `unicodeobject.c` are from `unicodectype.c` and they match values from `unicodetype_db.h` witch is generated by `Tools/unicode/makeunicodedata.py` which built those masks this way: # decimal digit, integer

Re: The Cost of Dynamism

On Sun, Mar 13, 2016 at 6:24 AM, Thomas 'PointedEars' Lahn wrote: > Marko Rauhamaa wrote: > >> […] HTML markup is all ASCII. > > Wrong. I am creating HTML documents whose source code contains Unicode > characters every day. > > Also, the two of you fail to differentiate

Re: Encapsulation in Python

On Sun, Mar 13, 2016 at 3:49 AM, Rick Johnson wrote: > Imagine this scenario: > > > # currentModule.py # > > from modX import foo > > def bar(): > return foo() > > ### > # modX.py #

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

BartC wrote: > On 12/03/2016 12:13, Marko Rauhamaa wrote: >> Why, look at the *English* page on Hillary Clinton: >> >> Hillary Diane Rodham Clinton /ˈhɪləri daɪˈæn ˈrɒdəm ˈklɪntən/ (born >> October 26, 1947) is an American politician. >> https://en.wikipedia.org/wiki/Hillary_Clinton>

Re: The Cost of Dynamism

Marko Rauhamaa wrote: > […] all keyboards can produce ASCII and no keyboard can produce all of > Unicode. Both claims are wrong. -- PointedEars Twitter: @PointedEars2 Please do not cc me. / Bitte keine Kopien per E-Mail. -- https://mail.python.org/mailman/listinfo/python-list

Re: The Cost of Dynamism

Marko Rauhamaa wrote: > […] HTML markup is all ASCII. Wrong. I am creating HTML documents whose source code contains Unicode characters every day. Also, the two of you fail to differentiate between US-ASCII, a 7-bit character encoding, and 8-bit or longer encodings which can *also* encode

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

On Sat, 12 Mar 2016 16:42:47 +, BartC wrote: > On 12/03/2016 15:30, Chris Angelico wrote: >> On Sun, Mar 13, 2016 at 2:12 AM, BartC wrote: > >>> However, I was going to revise my benchmark to use strings instead of >>> integers, to show how much slower they would be. But

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

On 12/03/2016 18:07, Marko Rauhamaa wrote: BartC : No it's very easy. In Python terms: def f(): return "One" def g(): return "Two" h=f h() returns "One". Later you do h=g, and h() returns "Two". No need for f and g themselves to be dynamic. h just needs to be a variable.

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

BartC : > No it's very easy. In Python terms: > > def f(): return "One" > def g(): return "Two" > > h=f > > h() returns "One". Later you do h=g, and h() returns "Two". No need > for f and g themselves to be dynamic. h just needs to be a variable. Well, what do you make of this:

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

On 12/03/2016 16:56, Steven D'Aprano wrote: On Sun, 13 Mar 2016 12:42 am, BartC wrote: Ad-hoc attributes I don't have as much of a problem with, as they can be handy. But predefined ones also have their points. (For one thing, I know how to implement those efficiently.) However, when you have

[issue25638] Verify the etree_parse and etree_iterparse benchmarks are working appropriately

Changes by Brett Cannon : -- resolution: -> not a bug status: open -> closed ___ Python tracker ___

Re: Descriptors vs Property

Veek. M wrote: > Veek. M wrote: >> class TypedProperty(object): >> def __init__(self,name,type,default=None): >> self.name = "_" + name >> self.type = type >> self.default = default if default else type() >> >> def __get__(self,instance,cls): >> return

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

On 12/03/2016 16:42, BartC wrote: On 12/03/2016 15:30, Chris Angelico wrote: On Sun, Mar 13, 2016 at 2:12 AM, BartC wrote: However, I was going to revise my benchmark to use strings instead of integers, to show how much slower they would be. But the program was 10% faster

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

On Sun, 13 Mar 2016 12:42 am, BartC wrote: > Ad-hoc attributes I don't have as much of a problem with, as they can be > handy. But predefined ones also have their points. (For one thing, I > know how to implement those efficiently.) > > However, when you have a function call like this: M.F(),

Re: Encapsulation in Python

On Friday, March 11, 2016 at 6:52:42 PM UTC-6, Gregory Ewing wrote: > Rick Johnson wrote: > > I have witnessed the mayhem that occurs when a language does > > not mandate module encapsulation (Ruby, i'm looking directly > > at you), and while i agree with the Python designers > > that modules

Re: Encapsulation in Python

On Fri, Mar 11, 2016 at 7:39 PM, Rick Johnson wrote: > At run-time, i don't care how large a "module namespace" may > be. Sometimes a module namespace will be small, with only a > few exposed symbols, but sometimes, a module namespace will > expose thousands of

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

On 12/03/2016 15:30, Chris Angelico wrote: On Sun, Mar 13, 2016 at 2:12 AM, BartC wrote: However, I was going to revise my benchmark to use strings instead of integers, to show how much slower they would be. But the program was 10% faster with strings! So there's

[issue26079] Build with Visual Studio 2015 using PlatformToolset=v120

Steve Dower added the comment: Python 2.7 has a different section in its tcltk.props file and doesn't need this fix (yet). Thanks for the patch, Bjoern! -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker

[issue26079] Build with Visual Studio 2015 using PlatformToolset=v120

Roundup Robot added the comment: New changeset 7617f5b3f263 by Steve Dower in branch '3.5': Issue #26079: Fixing the build output folder for tix-8.4.3.6. Patch by Bjoern Thiel. https://hg.python.org/cpython/rev/7617f5b3f263 New changeset f426178c9d6c by Steve Dower in branch 'default': Issue

[issue23606] ctypes.util.find_library("c") no longer makes sense

Steve Dower added the comment: That's a bit too much of a tangent for me to note in-place in the docs, but it'd be good content for a "Best practices" section (I seem to recall we had one somewhere, that basically started with "avoid ctypes if possible"...) Given we've heard no feedback about

[issue23606] ctypes.util.find_library("c") no longer makes sense

Roundup Robot added the comment: New changeset f9dc71b566fb by Steve Dower in branch '3.5': Issue #23606: Adds note to ctypes documentation regarding cdll.msvcrt. https://hg.python.org/cpython/rev/f9dc71b566fb New changeset 6d84fe4d8cb0 by Steve Dower in branch 'default': Issue #23606: Adds

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

On Sat, 12 Mar 2016 01:20 pm, Chris Angelico wrote: >>> Definitely agree with this. Having a way to declare that a name is >>> "truly constant" would be extremely handy; there currently isn't a >>> way, and I'm not sure whether FAT Python is looking into this or not. "Constants" would be a new

[issue19450] Bug in sqlite in Windows binaries

Steve Dower added the comment: Assigning to Benjamin to make the call for 2.7. Either close or assign it back if you want the update. -- assignee: steve.dower -> benjamin.peterson versions: -Python 3.5, Python 3.6 ___ Python tracker

[issue26513] platform.win32_ver() broken in 2.7.11

Roundup Robot added the comment: New changeset 5564cf3ba523 by Steve Dower in branch '3.5': Issue #26513: Fixes platform module detection of Windows Server https://hg.python.org/cpython/rev/5564cf3ba523 New changeset 9db5846f126d by Steve Dower in branch '2.7': Issue #26513: Fixes platform

[issue26513] platform.win32_ver() broken in 2.7.11

Changes by Steve Dower : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker ___

Re: Pyhon 2.x or 3.x, which is faster?

On Sat, 12 Mar 2016 10:31:39 +, BartC wrote: > On 12/03/2016 10:06, alister wrote: >> On Fri, 11 Mar 2016 22:24:45 +, BartC wrote: >> >>> On 11/03/2016 21:59, Mark Lawrence wrote: On 11/03/2016 18:57, BartC wrote: >>> def test(): s="" for i in

[issue26499] http.client.IncompleteRead from HTTPResponse read after part reading file

SilentGhost added the comment: OK, here is the patch including the tests that seem to exercise the behaviour. -- Added file: http://bugs.python.org/file42151/issue26499_4.diff ___ Python tracker

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

On Sun, Mar 13, 2016 at 2:12 AM, BartC wrote: > That explains why you rarely use integers, if you prefer to use strings even > when there is a choice! > > However, I was going to revise my benchmark to use strings instead of > integers, to show how much slower they would be. But

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

On Sat, 12 Mar 2016 11:08:25 +, BartC wrote: > > >> You're not mistaken. There are no "character constants" in Python. > >> (Note that the definition would be Unicode codepoints, rather than > >> ASCII values.) I don't often miss them, though. > >> Yes, a complete non-issue. > > Really?

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

On 12/03/2016 12:10, Chris Angelico wrote: On Sat, Mar 12, 2016 at 10:08 PM, BartC wrote: Writing: a=65 generates this byte-code for the right-hand-side: LOAD_CONST 1 (65) An integer But writing instead: a=ord('A') generates this: LOAD_GLOBAL 0

[issue25687] Error during test case and tearDown

Changes by Ezio Melotti : -- assignee: -> ezio.melotti stage: needs patch -> patch review ___ Python tracker ___

Re: Encapsulation in Python

On Saturday, March 12, 2016 at 3:43:16 AM UTC-6, dieter wrote: > > archives, and then stuff the link down your big fat mouth? > ^^^ > > What happened that you use language like this? Obviously, > you disagree with Steven - but this should

[issue26226] Various test suite failures on Windows

Ezio Melotti added the comment: > I'm surprised by the test_codecencodings_iso2022 failures. Example: == FAIL: test_incrementaldecoder (test.test_codecencodings_iso2022.Test_ISO2022_KR)

[issue26483] docs unclear on difference between str.isdigit() and str.isdecimal()

Anna Koroliuk added the comment: Hi, all! At Helsinki Python sprint I with the kind help of Ezio found two things. 1) This code gives results which are attached in the file. I will just now show some interesting cases where isdigit() and isdecimal() give different results. for c in map(chr,

[issue26546] Provide translated french translation on docs.python.org

New submission from Julien: Hi, The [french translation of the Python documentation](https://github.com/afpy/python_doc_fr) just hit a 21% coverage in terms of pageviews (According to statistics [nicely provided by

[issue26014] Guide users to the newer package install instructions

Susan Sun added the comment: Below two issues are fixed. * add See Also links to the modern docs from the legacy docs * append the (Legacy) suffix in the 2.x docs -- keywords: +patch nosy: +Susan Sun, ezio.melotti Added file: http://bugs.python.org/file42148/issue26014.diff

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

BartC : > Ad-hoc attributes I don't have as much of a problem with, as they can > be handy. But predefined ones also have their points. (For one thing, > I know how to implement those efficiently.) I wonder how large a proportion of all references are top-level. My hunch is that

[issue25638] Verify the etree_parse and etree_iterparse benchmarks are working appropriately

Serhiy Storchaka added the comment: I am not able to find the cause of the slowdown. I think this issue can be closed now. The etree_parse and etree_iterparse benchmarks are working appropriately and showing real regression in CPython 3.x. The cause of the regression is not known. --

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

BartC : > On 12/03/2016 12:13, Marko Rauhamaa wrote: >> BartC : >> >>> If you're looking at fast processing of language source code (in a >>> thread partly about efficiency), then you cannot ignore the fact >>> that the vast majority of characters being processed

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

On 12/03/2016 11:51, Marko Rauhamaa wrote: BartC : What's big deal with dynamism anyway? I could never understand Python's obsession with it. For me, 'dynamic' means that a variable has a dynamic type; that's all. But you know at compile-time (or when looking at source code)

Re: Encapsulation in Python

On Sat, Mar 12, 2016 at 8:42 PM, dieter wrote: > Rick Johnson writes: >> On Friday, March 11, 2016 at 3:28:40 AM UTC-6, Steven D'Aprano wrote: >> ... >> Are you sure about that? Heck, i posted code quite a few >> years back that "seg faulted

[issue26176] EmailMessage example doesn't work

HyeSoo Park added the comment: Could you please specify which example of the Provisional API among 2 examples of the documentation and how does it not work? Thank you -- nosy: +flyjwayur ___ Python tracker

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

On Sun, Mar 13, 2016 at 12:18 AM, BartC wrote: > On 12/03/2016 12:13, Marko Rauhamaa wrote: >> >> BartC : >> >>> If you're looking at fast processing of language source code (in a >>> thread partly about efficiency), then you cannot ignore the fact that >>> the

[issue26544] platform.libc_ver() returns incorrect version number

Marc-Andre Lemburg added the comment: Adding other Python versions as well, since this is a bug. -- versions: +Python 2.7, Python 3.4, Python 3.6 ___ Python tracker

[issue26544] platform.libc_ver() returns incorrect version number

Marc-Andre Lemburg added the comment: True. At the time the code was written, this was not an issue :-) Is the libc version information documented somewhere ? If so, we could probably add a better parser for it. -- ___ Python tracker

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

On 12/03/2016 12:13, Marko Rauhamaa wrote: BartC : If you're looking at fast processing of language source code (in a thread partly about efficiency), then you cannot ignore the fact that the vast majority of characters being processed are going to have ASCII codes. I don't

[issue18859] README.valgrind should mention --with-valgrind

Changes by Elena Oat : Added file: http://bugs.python.org/file42147/issue18859.diff ___ Python tracker ___

[issue18859] README.valgrind should mention --with-valgrind

Elena Oat added the comment: I've combined the patch submitted by Sowmya and also added there clarifications from points 1, 2 mentioned by Martin Mokrejs. -- nosy: +Elena.Oat ___ Python tracker

  1   2   >