Re: Possible bug in ThreadPoolExecutor, or just misinterpretation

On Mon, May 28, 2018 at 1:12 AM Santiago Basulto wrote: > Hey list! I might have encountered a "bug", or maybe it's just a "design > decision" :) > Here's some example code: > https://gist.github.com/santiagobasulto/3513a50ec0dc939e8f7bb2ecfa8d4ae2 > The problem is `ThreadPoolExecutor.map()`. I

Possible bug in ThreadPoolExecutor, or just misinterpretation

Hey list! I might have encountered a "bug", or maybe it's just a "design decision" :) Here's some example code: https://gist.github.com/santiagobasulto/3513a50ec0dc939e8f7bb2ecfa8d4ae2 The problem is `ThreadPoolExecutor.map()`. It's not returning tasks "as completed" but sequentially. I understa

Re: possible bug in while loop test

On 2017-09-02 18:53, Charles Hixson wrote: python3 --version Python 3.5.3 Running on Debian stretch In this code s is a string parameter while (j < k and \ (s[j].isalnum()) or \ (s[j] in seps and s[j+1].isalnum()) ): j = j + 1 print ("i = {0}, j =

Re: possible bug in while loop test

Charles Hixson wrote: > python3 --version > Python 3.5.3 > > Running on Debian stretch > > In this code s is a string parameter > > while (j < k and \ > (s[j].isalnum()) or \ >(s[j] in seps and s[j+1].isalnum()) ): > j = j + 1 > print ("i = {0}, j = {1

possible bug in while loop test

python3 --version Python 3.5.3 Running on Debian stretch In this code s is a string parameter while (j < k and \ (s[j].isalnum()) or \ (s[j] in seps and s[j+1].isalnum()) ): j = j + 1 print ("i = {0}, j = {1}, k = {2}, len[s] = {3}". \ format(i,

Re: Extra AttributeError inside property - possible bug ?

dunric...@gmail.com wrote: > Hello, > > bellow is a simple Python2 example of a class which defines __getattr__ > method and a property, where AttributeError exception is raised: > > from __future__ import print_function > > class MyClass(object): > def __getattr__(self, name): > pr

Extra AttributeError inside property - possible bug ?

Hello, bellow is a simple Python2 example of a class which defines __getattr__ method and a property, where AttributeError exception is raised: from __future__ import print_function class MyClass(object): def __getattr__(self, name): print('__getattr__ <<', name) raise Attri

Re: possible bug in re expression?

On 28/04/2014 12:49, Steven D'Aprano wrote: .. Well, I don't know about "almost any", but at least some broken regexes will explicitly fail: py> import re sre_constants.error: nothing to repeat (For brevity I have abbreviated the traceback.) so there is intent to catch some

Re: possible bug in re expression?

On Mon, 28 Apr 2014 10:47:54 +0100, Robin Becker wrote: > Does this in fact that almost any broken regexp specification will > silently fail because re will reset and consider any metacharacter as > literal? Well, I don't know about "almost any", but at least some broken regexes will explicitly

Re: possible bug in re expression?

On 25/04/2014 19:32, Terry Reedy wrote: .. I suppose that one could argue that '{' alone should be treated as special immediately, and not just when a matching '}' is found, and should disable other special meanings. I wonder what JS does if there is no matching '}'? well in fact I susp

Re: possible bug in re expression?

On Fri, 25 Apr 2014 14:32:30 -0400, Terry Reedy wrote: > On 4/25/2014 12:30 PM, Robin Becker wrote: [...] >> should >> >> re.compile('.{1,+3}') >> >> raise an error? It doesn't on python 2.7 or 3.3. > > And it should not because it is not an error. '+' means 'match 1 or more > occurrences of the

Re: possible bug in re expression?

On 4/25/2014 12:30 PM, Robin Becker wrote: Whilst translating some javascript code I find that this A=re.compile('.{1,+3}').findall(p) doesn't give any error, but doesn't manage to find the strings in p that I want len(A)==>0, the correct translation should have been A=re.compile('.{1,3}').fin

Re: possible bug in re expression?

On 2014-04-25 17:55, Chris Angelico wrote: On Sat, Apr 26, 2014 at 2:30 AM, Robin Becker wrote: Whilst translating some javascript code I find that this A=re.compile('.{1,+3}').findall(p) doesn't give any error, but doesn't manage to find the strings in p that I want len(A)==>0, the correct t

Re: possible bug in re expression?

On Sat, Apr 26, 2014 at 2:30 AM, Robin Becker wrote: > Whilst translating some javascript code I find that this > > A=re.compile('.{1,+3}').findall(p) > > doesn't give any error, but doesn't manage to find the strings in p that I > want len(A)==>0, the correct translation should have been > > A=re

possible bug in re expression?

Whilst translating some javascript code I find that this A=re.compile('.{1,+3}').findall(p) doesn't give any error, but doesn't manage to find the strings in p that I want len(A)==>0, the correct translation should have been A=re.compile('.{1,3}').findall(p) which works fine. should re.com

Re: Possible bug with stability of mimetypes.guess_* function output

On Saturday, February 8, 2014 10:39:06 AM UTC+2, Peter Otten wrote: > Asaf Las wrote: > > On Saturday, February 8, 2014 9:51:48 AM UTC+2, Peter Otten wrote: > >> At least the mimetypes already defined in the module could easily produce > >> the same guessed extension consistently. > > imho one work

Re: Possible bug with stability of mimetypes.guess_* function output

Asaf Las wrote: > On Saturday, February 8, 2014 9:51:48 AM UTC+2, Peter Otten wrote: >> >> At least the mimetypes already defined in the module could easily produce >> the same guessed extension consistently. > > imho one workaround for OP could be to supply own map file in init() thus > ensure

Re: Possible bug with stability of mimetypes.guess_* function output

On Saturday, February 8, 2014 9:51:48 AM UTC+2, Peter Otten wrote: > > At least the mimetypes already defined in the module could easily produce > the same guessed extension consistently. imho one workaround for OP could be to supply own map file in init() thus ensure unambiguous mapping across

Re: Possible bug with stability of mimetypes.guess_* function output

Asaf Las wrote: > On Friday, February 7, 2014 9:40:06 PM UTC+2, Peter Otten wrote: >> You never see ".shtml" as the guessed extension because it is not in the >> original mimetypes.types_map dict, but instead programmaticaly read from >> a file like /etc/mime.types and then added to a list of ext

Re: Possible bug with stability of mimetypes.guess_* function output

On Friday, February 7, 2014 9:40:06 PM UTC+2, Peter Otten wrote: > As Johannes mentioned, this depends on the hash seed: > $ PYTHONHASHSEED=0 python3 -c 'print({".htm", ".html", ".shtml"}.pop())' > .html > $ PYTHONHASHSEED=1 python3 -c 'print({".htm", ".html", ".shtml"}.pop())' > .htm > $ PYTHONHAS

Re: Possible bug with stability of mimetypes.guess_* function output

Asaf Las wrote: > On Friday, February 7, 2014 8:06:36 PM UTC+2, Johannes Bauer wrote: >> Hi group, >> >> I'm using Python 3.3.2+ (default, Oct 9 2013, 14:50:09) [GCC 4.8.1] on >> linux and have found what is very peculiar behavior at best and a bug at >> worst. It regards the mimetypes module an

Re: Possible bug with stability of mimetypes.guess_* function output

On 07.02.2014 20:09, Asaf Las wrote: > it might be you could try to query using sequence below : > > import mimetypes > mimetypes.init() > mimetypes.guess_extension("text/html") > > i got only 'htm' for 5 consequitive attempts Doesn't change anything. With this: #!/usr/bin/python3 import mime

Re: Possible bug with stability of mimetypes.guess_* function output

On 07/02/2014 19:17, Asaf Las wrote: btw, had seen this after own post - example usage includes mimetypes.init() before call to module functions. From http://docs.python.org/3/library/mimetypes.html#module-mimetypes third paragraph "The functions described below provide the primary interface

Re: Possible bug with stability of mimetypes.guess_* function output

btw, had seen this after own post - example usage includes mimetypes.init() before call to module functions. -- https://mail.python.org/mailman/listinfo/python-list

Re: Possible bug with stability of mimetypes.guess_* function output

On Friday, February 7, 2014 8:06:36 PM UTC+2, Johannes Bauer wrote: > Hi group, > > I'm using Python 3.3.2+ (default, Oct 9 2013, 14:50:09) [GCC 4.8.1] on > linux and have found what is very peculiar behavior at best and a bug at > worst. It regards the mimetypes module and in particular the > gu

Possible bug with stability of mimetypes.guess_* function output

Hi group, I'm using Python 3.3.2+ (default, Oct 9 2013, 14:50:09) [GCC 4.8.1] on linux and have found what is very peculiar behavior at best and a bug at worst. It regards the mimetypes module and in particular the guess_all_extensions and guess_extension functions. I've found that these do not

Re: Possible bug in string handling (with kludgy work-around)

On 12/28/2011 11:57 AM, Rick Johnson wrote: On Dec 27, 3:38 pm, Terry Reedy wrote: On 12/27/2011 1:04 PM, Rick Johnson wrote: But this brings up a very important topic. Why do we even need triple quote string literals to span multiple lines? Good question, and one i have never really mused on

Re: Possible bug in string handling (with kludgy work-around)

On Dec 27, 3:38 pm, Terry Reedy wrote: > On 12/27/2011 1:04 PM, Rick Johnson wrote: > > > But this brings up a very important topic. Why do we even need triple > > quote string literals to span multiple lines? Good question, and one i > > have never really mused on until now. > > I have, and the r

Re: Possible bug in string handling (with kludgy work-around)

On 12/27/2011 1:04 PM, Rick Johnson wrote: But this brings up a very important topic. Why do we even need triple quote string literals to span multiple lines? Good question, and one i have never really mused on until now. I have, and the reason I thought of is that people, including me, too o

Re: Possible bug in string handling (with kludgy work-around)

On 12/28/2011 05:04 AM, Rick Johnson wrote: -- Note: superfluous indention removed for clarity! -- On Dec 27, 8:53 am, Dennis Lee Bieber wrote: You can get by without the backslash in this situation too, by using triple quoting: I would not do that because: 1. Because Python already has TWO

Re: Possible bug in string handling (with kludgy work-around)

-- Note: superfluous indention removed for clarity! -- On Dec 27, 8:53 am, Dennis Lee Bieber wrote: > You can get by without the backslash in this situation too, by using > triple quoting: I would not do that because: 1. Because Python already has TWO string literal delimiters (' and ") 2. Becau

Re: Possible bug in string handling (with kludgy work-around)

That was it! Thanks. On 12/26/2011 02:44 PM, Chris Angelico wrote: On Tue, Dec 27, 2011 at 9:23 AM, Charles Hixson wrote: This doesn't cause a crash, but rather incorrect results. You may need to be a bit clearer. What line of code (or what expression)? What did you expect to see,

Re: Possible bug in string handling (with kludgy work-around)

On Mon, 26 Dec 2011 14:23:03 -0800, Charles Hixson wrote: > This doesn't cause a crash, but rather incorrect results. Charles, your code is badly formatted and virtually unreadable. You have four spaces between some tokens, lines are too long to fit in an email or News post without word-wrappin

Re: Possible bug in string handling (with kludgy work-around)

On Tue, Dec 27, 2011 at 9:48 AM, Rick Johnson wrote: > Handy rules for reporting bugs: > > 1. Always format code properly. > 2. Always trim excess fat from code. > 3. Always include relative dependencies ("self.wordlist" is only valid > inside a class. In this case, change the code to a state that

Re: Possible bug in string handling (with kludgy work-around)

On Dec 26, 4:23 pm, Charles Hixson wrote: > This doesn't cause a crash, but rather incorrect results. > > self.wordList    =    ["The", "quick", "brown", "fox", "carefully", >                  "jumps", "over", "the", "lazy", "dog", "as", "it", >                  "stealthily", "wends", "its", "way"

Re: Possible bug in string handling (with kludgy work-around)

On Tue, Dec 27, 2011 at 9:23 AM, Charles Hixson wrote: > This doesn't cause a crash, but rather incorrect results. You may need to be a bit clearer. What line of code (or what expression)? What did you expect to see, and what did you see? >From examining your code, I've come up with one most-lik

Possible bug in string handling (with kludgy work-around)

This doesn't cause a crash, but rather incorrect results. self.wordList=["The", "quick", "brown", "fox", "carefully", "jumps", "over", "the", "lazy", "dog", "as", "it", "stealthily", "wends", "its", "way", "homewards", '\b.'] foriinrange (len (s

Possible bug in multiprocessing.Queue() on Ubuntu

Hello, While working with the multiprocessing module in Python 2.6.6 on Ubuntu 10.10 64-bit, the following exception was raised: >>> import multiprocessing >>> input_queue = multiprocessing.Queue() Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.6/multiprocessin

Re: Possible bug in Tkinter - Python 2.6

On Monday 19 January 2009 09:24:09 Eric Brunel wrote: > This is not the procedure I describe in the original post. The first time, >   it works for me too. It's only after I used the file dialog that it stops > working. You are right, my mistake. -- José Abílio -- http://mail.python.org/mailman/

Re: Possible bug in Tkinter - Python 2.6

On Sun, 18 Jan 2009 01:57:12 +0100, José Matos wrote: On Friday 16 January 2009 09:47:36 Eric Brunel wrote: What do you mean by 'works'...? The usual meaning, I think. :-) Click "Yes" and the program prints True, click "No" and the programs prints "False". This is not the procedure I d

Re: Possible bug in Tkinter - Python 2.6

On Fri, 16 Jan 2009 17:49:50 +0100, Terry Reedy wrote: Eric Brunel wrote: On Thu, 15 Jan 2009 23:49:22 +0100, Terry Reedy wrote: Eric Brunel wrote: [snip]>> And BTW, if this is actually a bug, where can I report it? bugs.python.org Thanks. I reported the problem. When you report tha

Re: Possible bug in Tkinter - Python 2.6

On Friday 16 January 2009 09:47:36 Eric Brunel wrote: > What do you mean by 'works'...? The usual meaning, I think. :-) Click "Yes" and the program prints True, click "No" and the programs prints "False". > You don't have the problem? It doesn't   > change a thing for me... Notice that I am ru

Re: Possible bug in Tkinter - Python 2.6

Eric Brunel wrote: On Thu, 15 Jan 2009 23:49:22 +0100, Terry Reedy wrote: Eric Brunel wrote: [snip]>> And BTW, if this is actually a bug, where can I report it? bugs.python.org Thanks. I reported the problem. When you report that you reported to problem to the tracker (a good idea), pl

Re: Possible bug in Tkinter - Python 2.6

On Thu, 15 Jan 2009 23:49:22 +0100, Terry Reedy wrote: Eric Brunel wrote: [snip]>> And BTW, if this is actually a bug, where can I report it? bugs.python.org Thanks. I reported the problem. -- python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-']

Re: Possible bug in Tkinter - Python 2.6

On Thu, 15 Jan 2009 19:09:00 +0100, José Matos wrote: On Thursday 15 January 2009 15:28:36 r wrote: First of all be very careful using from "module" import * or you will have name conflicts. Tkinter is made to be imported this way and i do it all the time. for the others do. import tkMessageB

Re: Possible bug in Tkinter - Python 2.6

Eric Brunel wrote: Hi all, I found a behaviour that might be a bug in Tkinter for Python 2.6. Here is the script: - from Tkinter import * from tkMessageBox import * from tkFileDialog import * root = Tk() def ask_file(): file_name = askopenfilename() print fil

Re: Possible bug in Tkinter - Python 2.6

On Thursday 15 January 2009 15:28:36 r wrote: > First of all be very careful using from "module" import * or you will > have name conflicts. Tkinter is made to be imported this way and i do > it all the time. for the others do. > > import tkMessageBox as MB > import tkFileDialog as FD > or whatever

Re: Possible bug in Tkinter - Python 2.6

First of all be very careful using from "module" import * or you will have name conflicts. Tkinter is made to be imported this way and i do it all the time. for the others do. import tkMessageBox as MB import tkFileDialog as FD or whatever floats your boat. Secondly i hear all the time about prob

Re: Possible bug in Tkinter - Python 2.6

On 15 Gen, 11:30, "Eric Brunel" wrote: > Hi all, > > I found a behaviour that might be a bug in Tkinter for Python 2.6. Here is   > the script: > > - >  from Tkinter import * >  from tkMessageBox import * >  from tkFileDialog import * > > root = Tk() > > def ask_file():

Possible bug in Tkinter - Python 2.6

Hi all, I found a behaviour that might be a bug in Tkinter for Python 2.6. Here is the script: - from Tkinter import * from tkMessageBox import * from tkFileDialog import * root = Tk() def ask_file(): file_name = askopenfilename() print file_name def ask_con

Re: Possible bug in Tkinter for Python 2.6

On Wed, 19 Nov 2008 18:51:03 +0100, Terry Reedy <[EMAIL PROTECTED]> wrote: Anton Vredegoor wrote: On Wed, 19 Nov 2008 10:57:53 +0100 "Eric Brunel" <[EMAIL PROTECTED]> wrote: I'm trying out Python 2.6 and I found what might be a bug in the Tkinter module. How can I report it? maybe here: htt

Re: Possible bug in Tkinter for Python 2.6

Anton Vredegoor wrote: On Wed, 19 Nov 2008 10:57:53 +0100 "Eric Brunel" <[EMAIL PROTECTED]> wrote: I'm trying out Python 2.6 and I found what might be a bug in the Tkinter module. How can I report it? maybe here: http://bugs.python.org/issue3774 The fix will be in 2.6.1, which might be in D

Re: Possible bug in Tkinter for Python 2.6

On Wed, 19 Nov 2008 10:57:53 +0100 "Eric Brunel" <[EMAIL PROTECTED]> wrote: > I'm trying out Python 2.6 and I found what might be a bug in the > Tkinter module. How can I report it? maybe here: http://bugs.python.org/issue3774 > The possible bug is a traceback whe

Re: Possible bug in Tkinter for Python 2.6

On Wed, Nov 19, 2008 at 4:57 AM, Eric Brunel <[EMAIL PROTECTED]> wrote: > Hello all, > > I'm trying out Python 2.6 and I found what might be a bug in the Tkinter > module. How can I report it? > > The possible bug is a traceback when trying to delete a menu item in

Possible bug in Tkinter for Python 2.6

Hello all, I'm trying out Python 2.6 and I found what might be a bug in the Tkinter module. How can I report it? The possible bug is a traceback when trying to delete a menu item in a menu where no items have associated commands. For example: -- from Tk

Re: Possible bug in Python 2.5? (Was Re: pdb in python2.5)

> * comp.lang.python is not the place to file bug reports Agreed > * more detail is needed that what's been given so far Agreed. I will investigate further when I get a chance and determine if it's a problem on my end. Thanks a lot! -- http://mail.python.org/mailman/listinfo/python-list

Re: Possible bug in Python 2.5? (Was Re: pdb in python2.5)

"Rotem" <[EMAIL PROTECTED]> writes: > Hi, > > I noticed that pydb.pm() also fails in python2.5 when invoked on that > same example (seems like also trying to access a nonexistent > attribute/variable). > > Is this known to you as well/was it fixed? Doesn't do that for me for Python 2.5 on both

Re: Possible bug in Python 2.5? (Was Re: pdb in python2.5)

Hi, I noticed that pydb.pm() also fails in python2.5 when invoked on that same example (seems like also trying to access a nonexistent attribute/variable). Is this known to you as well/was it fixed? On Jan 25, 9:15 pm, [EMAIL PROTECTED] (R. Bernstein) wrote: > I'd like to change my assessment of

Possible bug in Python 2.5? (Was Re: pdb in python2.5)

I'd like to change my assessment of whether the problem encountered is a pdb bug or not. It could be a bug in Python. (Right now it is only known to be a bug in version 2.5.) For a given traceback t, the question is whether t.tb_frame.f_lineno can ever be different from t.tb_lineno. Still, for no

Re: Argument Precedence (possible bug?)

"vbgunz" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hello, Steven D'Aprano, Terry Jan Reedy! > > I would really like to extend my thanks to you guys. I hope I've got it > right this time! > > def posKeyArgs(a, b=2, c=3): >print a, b, c > > #posKeyArgs(b=20) # too few posit

Re: Argument Precedence (possible bug?)

Hello, Steven D'Aprano, Terry Jan Reedy! I would really like to extend my thanks to you guys. I hope I've got it right this time! def posKeyArgs(a, b=2, c=3): print a, b, c #posKeyArgs(b=20) # too few positional arguments. a needs an arg. #posKeyArgs(10, c=30, 20) # pos_args cannot follow

Re: Argument Precedence (possible bug?)

"vbgunz" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hello all, > > I am just learning Python and have come across something I feel might > be a bug. I feel it is more likely that there in a bug in the communication process from the manual to you, on an admittedly somewhat con

Re: Argument Precedence (possible bug?)

Please allow me some time to look at your examples. I get hung up over the smallest details because in my mind, my approach should have just worked... I learned about these parameters reading "O'reilly Learning Python 2nd Edition". On page 217 of the paperback or Chapter 13.5.6 in the ebook, topic:

Re: Argument Precedence (possible bug?)

I am sorry I hung you up on a typo Peter Hansen. On line 5 *arg4 should have been *par4. I hope it makes complete sense now. Sorry. -- http://mail.python.org/mailman/listinfo/python-list

Re: Argument Precedence (possible bug?)

On Sun, 05 Mar 2006 04:45:05 -0800, vbgunz wrote: > PS. I could be far off with this codes purpose; to try and create an > example that will house all the different possible parameters > (positional, keyword, * and **) in one single def statement. This is usually a bad idea, not because Python ca

Re: Argument Precedence (possible bug?)

On Sun, 05 Mar 2006 04:45:05 -0800, vbgunz wrote: > Hello all, > > I am just learning Python and have come across something I feel might > be a bug. Please enlightenment me... The following code presents a > challenge. How in the world do you provide an argument for *arg4? > > ## ===

Re: Argument Precedence (possible bug?)

vbgunz wrote: > I am just learning Python and have come across something I feel might > be a bug. Please enlightenment me... The following code presents a > challenge. How in the world do you provide an argument for *arg4? Maybe by putting that in the list of arguments? ... You don't even *have*

Re: Argument Precedence (possible bug?)

"vbgunz" wrote: > I am just learning Python and have come across something I feel might > be a bug. Please enlightenment me... The following code presents a > challenge. How in the world do you provide an argument for *arg4? > > ## > def

Re: Argument Precedence (possible bug?)

Hello all, I am just learning Python and have come across something I feel might be a bug. Please enlightenment me... The following code presents a challenge. How in the world do you provide an argument for *arg4? ## def argPrecedence(p

Re: Argument Precedence (possible bug?)

Please forgive my call() Change this: argPrecedence('arg1', arg3='arg3', arg2='arg2', arg5='arg5') to this: argPrecedence('arg1', par3='arg3', par2='arg2', arg5='arg5') Thanks! -- http://mail.python.org/mailman/listinfo/python-list

Argument Precedence (possible bug?)

Hello all, I am just learning Python and have come across something I feel might be a bug. Please enlightenment me... The following code presents a challenge. How in the world do you provide an argument for *arg4? ## def argPrecedence(p

Argument Precedence (possible bug?)

Hello all, I am just learning Python and have come across something I feel might be a bug. Please enlightenment me... The following code presents a challenge. How in the world do you provide an argument for *arg4? ## def argPrecedence(p

Re: possible bug in cherrypy.lib.autoreload

Ok, so it turns out that the problem the cherrypy.lib.autoreload module is having, is that kid imports elementtree and on my machine the elementtree modules are inside a zip file (.egg). So the "path" to the elementtree __init__.py file is not a valid OS path because everything after the .egg file

possible bug in cherrypy.lib.autoreloader

I may have found the source of my infinite loop when importing kid modules from my cherrypy server. Here is some code from the autoreloader module of cherrypy: def reloader_thread(): mtimes = {} def fileattr(m): return getattr(m, "__file__", None) while RUN_RELOADER:

Re: Possible bug in "metaclass resolution order" ?

On Mon, 19 Sep 2005 05:22:09 GMT [EMAIL PROTECTED] (Bengt Richter) wrote: > > And the something returned, whatever it is, if no checking is > triggered by normal use, gets bound to the class name, e.g., Yes... this is the intended behaviour. In fact, the issue is already solved and is really jus

Re: Possible bug in "metaclass resolution order" ?

On Sat, 17 Sep 2005 12:41:09 -0300, Pedro Werneck <[EMAIL PROTECTED]> wrote: >On 17 Sep 2005 02:04:39 -0700 >"Simon Percivall" <[EMAIL PROTECTED]> wrote: > >> Have you read the "Metaclasses" part of "Unifying types and classes in >> Python 2.2"? (http://www.python.org/2.2.3/descrintro.html#metacla

Re: Possible bug in "metaclass resolution order" ?

On 18 Sep 2005 12:58:22 -0700 "Simon Percivall" <[EMAIL PROTECTED]> wrote: > I definitely think that it's the intended behaviour: the example shows > how and why it works; and I definitely agree that it should be > documented better. Yes. I finally understood the decision and now I agree it's not

Re: Possible bug in "metaclass resolution order" ?

I definitely think that it's the intended behaviour: the example shows how and why it works; and I definitely agree that it should be documented better. -- http://mail.python.org/mailman/listinfo/python-list

Re: Possible bug in "metaclass resolution order" ?

On 18 Sep 2005 10:33:11 -0700 "Simon Percivall" <[EMAIL PROTECTED]> wrote: > Isn't that exactly what you are doing? Yes, and that example has the same inconsistency. >>> class X(type): pass ... >>> class D2(C3, C2): __metaclass__ = X ... Traceback (most recent call last): File "", line 1, i

Re: Possible bug in "metaclass resolution order" ?

If you have read the document I referred you to, did you also read the example where classes M1, M2, M3 and M4 were defined? A quote from the discussion of that example: "For class D, the explicit metaclass M1 is not a subclass of the base metaclasses (M2, M3), but choosing M3 satisfies the constr

Re: Possible bug in "metaclass resolution order" ?

On 18 Sep 2005 00:39:31 -0700 "Michele Simionato" <[EMAIL PROTECTED]> wrote: > Remember that given a class C, its metaclass is given by C.__class__, > not by > C.__metaclass__, despite the name. Of course. Seems you think I'm arguing that C.__class__ and __metaclass__ should always be the same. T

Re: Possible bug in "metaclass resolution order" ?

Pedro Werneck wrote: >>> class M_A(type): pass ... >>> class A: __metaclass__ = M_A ... >>> class M_B(M_A): pass ... >>> class B(A): __metaclass__ = M_B ... >>> class C(B): __metaclass__ = M_A ... >>> C.__class__ >>> C.__metaclass__ > Is this supposed to happen ? Yes, or at least I fee

Re: Possible bug in "metaclass resolution order" ?

On Sat, 17 Sep 2005 15:07:01 -0400 "Terry Reedy" <[EMAIL PROTECTED]> wrote: > If, after any further responses, you still think you have discovered a > bug, do file a report on SourceForge. Thanks... report id 1294232, Error in metaclass search order http://sourceforge.net/tracker/index.php?fun

Re: Possible bug in "metaclass resolution order" ?

"Pedro Werneck" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I still think this is a bug, not a documentation issue. As an sometimes bug report reviewer, I appreciate your posting this issue here to get a wider and quicker variety of responses than you might have on SF. If, a

Re: Possible bug in "metaclass resolution order" ?

On 17 Sep 2005 08:51:50 -0700 "Michele Simionato" <[EMAIL PROTECTED]> wrote: Hi > I think this is more of a documentation issue than of a bug. No... I don't think it's a documentation issue. What's the problem with the documentation in this case ? Trying to use 'type' as a metaclass with a subcl

Re: Possible bug in "metaclass resolution order" ?

I think this is more of a documentation issue than of a bug. It may seems strange at first, but __metaclass__ and __class__ may be different. For instance, if M is metaclass >>> class C(object): pass >>> C.__metaclass__ = M you get a class with metaclass hook equal to M, but C.__class__ is stil

Re: Possible bug in "metaclass resolution order" ?

On 17 Sep 2005 02:04:39 -0700 "Simon Percivall" <[EMAIL PROTECTED]> wrote: > Have you read the "Metaclasses" part of "Unifying types and classes in > Python 2.2"? (http://www.python.org/2.2.3/descrintro.html#metaclasses) Yes, I read. Have you read and understood my message ? :) A class B, subcla

Re: Possible bug in "metaclass resolution order" ?

Have you read the "Metaclasses" part of "Unifying types and classes in Python 2.2"? (http://www.python.org/2.2.3/descrintro.html#metaclasses) It discusses and explains the issues you seem to have. -- http://mail.python.org/mailman/listinfo/python-list

Possible bug in "metaclass resolution order" ?

Hi I have a class A, with metaclass M_A, and class B, subclass of A, with metaclass M_B, subclass of M_A. A class C, subclass of B must have M_B or a subclass of it as metaclass, but what if I need to 'disable' the code in M_B on C ? The correct way to do that seems to be with a M_C metaclass, s

Re: Streaming Data Error in .read() (HTTP/ICY) Possible Bug?

I should purhaps mention that i am basically trying to translate this. nc ~= telnet #!/bin/sh nc sc1.liquidviewer.com 9012

Streaming Data Error in .read() (HTTP/ICY) Possible Bug?

I playing around with streaming shoutcast mp3s. Here is some sample code: --- import httplib # Put together the headers headers = {"Icy-MetaData":"1"} con = httplib.HTTPConnection('64.142.8.154', 8000) con.request("GET", "/") stream = con.getresponse() print str

Re: file corruption on windows - possible bug

On Mon, 09 May 2005 10:54:22 -0400, Jeremy Jones <[EMAIL PROTECTED]> wrote: >I've written a piece of code that iterates through a list of items and >determines the filename to write some piece of data to based on >something in the item itself. Here is a small example piece of code to >show the ty

Re: file corruption on windows - possible bug

Fredrik Lundh wrote: Jeremy Jones wrote: # file_dict = {} a_list = [("a", "a%s" % i) for i in range(2500)] b_list = [("b", "b%s" % i) for i in range(2500)] c_list = [("c", "c%s" % i) for i in range(2500)] d_list = [("d", "d%s" % i) for i in range(2

Re: file corruption on windows - possible bug

Fredrik Lundh wrote: > you do realize that this opens the file again every time, so you end > up having 4x2500 file handles pointing to 4 physical files. that's a > bad idea. > Assuming he is using the common C Python most of those file handles get closed immediately after opening, so he never

Re: file corruption on windows - possible bug

Jeremy Jones wrote: > Here is a small example piece of code to > show the type of thing I'm doing:: > > # > file_dict = {} > > a_list = [("a", "a%s" % i) for i in range(2500)] > b_list = [("b", "b%s" % i) for i in range(2500)] > c_list = [("c", "c%s" % i) for i in

Re: file corruption on windows - possible bug

Jeremy Jones wrote: > # > file_dict = {} > > a_list = [("a", "a%s" % i) for i in range(2500)] > b_list = [("b", "b%s" % i) for i in range(2500)] > c_list = [("c", "c%s" % i) for i in range(2500)] > d_list = [("d", "d%s" % i) for i in range(2500)] > > > joined_list =

file corruption on windows - possible bug

I've written a piece of code that iterates through a list of items and determines the filename to write some piece of data to based on something in the item itself. Here is a small example piece of code to show the type of thing I'm doing:: # file_dict = {} a_list

Re: possible bug?

Earl Eiland wrote: There may be different ways to code it. This works. You're right about that, *as the code now stands*. The danger is that you are using single backslashes. The *only* reason this works right now is because none of the characters you have following those backslashes happen to b

Re: possible bug?

There may be different ways to code it. This works. The problem is that occasionally somehow, WinRK terminates without terminating the process, or at least Python doesn't pick up the return code. It turns out that using poll() instead of wait() only reduces the error frequency, and allows me to r

Re: possible bug?

Earl Eiland <[EMAIL PROTECTED]> wrote: >I'm running the following code on Windows 2000, 5.00.2195: > >for x in Files: > Command_String = 'C:\Program Files\WinRK\WinRK.exe -create ' + That can't be right. You need either Command_String = 'C:\\Program Files\\WinRK\\WinRK.exe -create

  1   2   >